You are here
Rob S - Tue, 2013/12/10 - 22:51
I have run out of disk space on my root partition thanks to Duplicity files. This is Turnkey 12 Redmine hosted on Amazon.
I have 10GB but I see 20GB is advertised as the new norm for a small server. What is the easiest way to get up to at least 20GB for the root partition?
I found the LVM howto blog post, but vgdisplay shows no volume groups!?
Rob
Forum:
Alternative: fix duplicity?
I understand TKLBAM is using duplicty and that's what is filling up the root partition regularly.
Can I just move /var/cache/duplicty to /tmp to solve this problem?
Here is the output of df after deleting duplicity files:
Filesystem 1K-blocks Used Available Use% Mounted on
/dev/xvda1 10321208 6301212 3495708 65% /
tmpfs 868680 0 868680 0% /lib/init/rw
udev 847284 28 847256 1% /dev
tmpfs 868680 0 868680 0% /dev/shm
/dev/xvda2 153899044 192272 145889148 1% /mnt
overflow 153899044 192272 145889148 1% /tmp
A couple of things...
Firstly if I were you I'd be looking to migrate to the v13.0 appliances soonish regardless as they are based on Debian Wheezy/7 (and the basis for 12.x is Debian Squeeze/6 which only has ~5mths of security updates left). Although that probably won't change things substantially (although will get you the default 20GB root AFAIK).
IIRC LVM doesn't apply to AWS hosted appliances, so that's why that command didn't work...
There is also a new version of TKLBAM (default in v13.0, optional in v12.x) although whether or not that changes the behaviour of duplicity in regards to caching is probably unlikely IMO (although who knows...) AFAIK the reason why duplicity keeps the cache is to allow the running of incremental backups, so the unintended consequence of deleteing them is that your backups will be bigger (they will need to be full backups) or perhaps it will cause it to error? (because it can't find the cached files...?) Although perhaps it keeps more than it really needs...? (More questions than answers eh...!?)
Finally you should be able to mount --bind the duplicity cache to tmp, but whether that will actually be beneficial or not I'm not convinced... I'm not sure how it works in AWS but on bare metal installs tmp is usually resident in RAM so hainvg it chocked full of cache is rarely beneficial to the operation of your server... Also if/when the appliance is restarted you'll lose all the cache (tmp is emptied on halt/reboot) which may have unintended consequence (see above paragraph).
Managing disk space / upgrading
Moving the duplicity files off of the root partition to /tmp did not appear to cause any problems. At least on my instance on AWS /tmp is 160 GB of instance storage. So it should persist as long as I don't shut off the instance. Although deleting those files also didn't seem to have any impact that I noticed.
Please tell me I'm mistaken, but doesn't upgrading to another turnkey release mean starting all over from scratch on a new instance and having to redo all configuration and customizations!?
Good to hear! :)
OK yeah I forgot about tmp being storage (rather than in RAM/swap on bare metal installs).
No you don't need to start from scratch, you just migrate your data (i.e. restore your TKLBAM backup to a new server - that's what the M stands for in TKLBAM - TurnKey Linux Backup And Migration!). You may need to make a few tweaks and adjustments though. I have found TKLBAM pretty reliable, but I wouldn't destory your current server until you are sure that the migration has gone smoothly and everything is working in your new server...
Migration questions
Obviously migrating to a different instance is easy, but I don't think that migrating to a new TKL version is at all easy. I expect that TKLBAM is not smart enough to upgrade your databases to those required for newer application versions for you.
If security releases for v12 are only available for 5 more months, why in the world is TKL using Debian? Redhat/CentOS have a 10 year security update policy.
Add new comment