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: 

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

 

 

Jeremy Davis's picture

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).

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!?

 

 

Jeremy Davis's picture

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...

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