Free up disk space

Sometimes you may find yourself needing to clear some free space on your server. You can do that proactively, but may find yourself needing to do that when your disk space runs critically low - especially if you run out altogether.

• Temporary clean up
  • Backup cache
  • Clean up apt package lists
  • Other caches
• Less temporary clean up
  • Apt packages
    • Apt's package cache
    • Redundant packages
  • Vacuum the journal
• Permanently reduce disk usage
  • Make apt always remove new deb files are package install
  • Reduce journal size permanently
• Final words

The only real solution to lack of disk space is to add more more space, such as increasing the size of your root volume. There are a number of options to add additional space. But I'll leave that for another day. Here, I'll cover some quick and easy ways to clear up free space.

First I'll cover some (very) temporary methods to recover disk space. Next, I'll cover some less temporary methods. Finally I'll note some permanent methods.

Note that these instructions assume that you are running as the root user. For Amazon Marketplace users, change to the root user like this:

sudo su -

Temporary clean up

All of these are temporary. These are most useful if you have an emergency. They are particularly useful in an emergency - particularly if the lack of space is causing issues with important services. These will give you a little breathing space, enough to increase your root volume size, and/or look at other more long lasting methods to recover disk space.

Backup cache

If you are a TKLBAM user, then a really quick way to clear space is to delete the backup cache. Note that your backups will not be affected, it just deletes the local cache. It's also important to note that this is the most temporary way to clear space.

TKLBAM caches files when creating backups and particularly when restoring a backup. They will be repopulated when a new full backup runs or next time you try to restore a backup. It's likely obvious why a restore will use up disk space and if you need to restore, then ill be far from ideal. Caching when doing a full backup may also be relatively obvious, although the importance of cached files for incremental backups may not be quite so intuitive. When doing incremental backups, TKLBAM needs to store info about your previous backups. Otherwise it won't know what files have changed since the last backup. It's as simple as deleting the files from the cache locations:

The TKLBAM cache locations are in the most common place Linux stores it's cache; /var/cache. Namely, /var/cache/tklbam (decrypted backup volumes) and /var/cache/duplicity (downloaded/ uploaded encrypted volumes). You can just delete the contents of these 2 directories completely:

rm -rf /var/cache/duplicity/*
rm -rf /var/cache/tklbam/*

If you've had a failed backup or restore, then depending on where it failed, there may also be another directory. This is the directory where the files to include in the backup or restore are temporarily stored. Generally it will not exist, but you can run this command to ensure it isn't:

rm -rf /TKLBAM

Clean up apt package lists

When you run 'apt update', lists of all available packages are downloaded. These files can safely be removed. Although they will be downloaded again next time that 'apt update' runs - including the automatic TurnKey security updates. Note that until you rerun 'apt update' apt will not act as your expect and will not be able to install any new packages. Similar to the TKLBAM cleanup above, this is really only a very temporary method.

find /var/lib/apt/lists -type f -exec rm {} \;

Important note that blindly removing files from any directory in /var/lib is not a good idea. Many apps store important data there. I know that this is safe, but removing other files in /var/lib may cause data loss.

Other caches

Other caches can also be cleaned. Although this is generally not a great option unless you really need the space. Often they don't take up much space and in corner cases may cause you more issues than worth it. Regardless, for completeness, I'll include this here. Please skip ahead if you'd rather, otherwise read on.

All files in /var/cache are considered "volatile". So long as the base directory remains (e.g. /var/cache/APP_NAME) the app should be able to reproduce the directory tree that it uses and rebuild it's required cache when it next runs.

Some of these cache cleans will be more permanent that others. How long it might take to build up the cache size will depend on the app. The amount of size the rebuilt cache takes up, may or may not be the same as the original cache size - it just depends on the app and how much cache history it keeps.

TKLBAM (as covered above) complies with this "requirement". These days most - if not all - apps should also comply with this. I've never hit an app that will fails if you remove it's cache files. Although some time ago, I did have problems with one app if you deleted the directory tree. Worst case scenario, reinstalling the app will resolve the issue:

apt install --reinstall APP_NAME

If you have any reservations about a particular app - and don't have immediate need to clear space, either just leave it be, or copy the directory tree before deleting files. To create a full copy of the cache directory before running below command to clear the cache:

cp -Ra /var/cache/APP_NAME /var/cache/APP_NAME.orig

One last thing before I get to the command to clean cache files, it's worth noting that some apps may include individual tools to clear their caches (see apt below). If they do include this functionality I recommend using them instead of doing it manually.

So to just delete the cached files for a particular app:

find /var/cache/APP_NAME -type f -exec rm {} \;

Less temporary clean up

Apt packages

Beyond the apt list files noted above, there are 2 other ways to clean up apt related files. In the long term, clearing these apt related files is also temporary. Although they are more permanent than the above because old files are permanently removed and it will take time for more files to accumulate.

Apt's package cache

This will clean the cached packages that have been downloaded and likely already installed. Cleaning these is super quick and easy and perhaps even more importantly, very safe. Clear the apt cache like this:

apt clean

As simple as that. :)

Redundant packages

The other way that apt can take up space is redundant installed packages that are no longer needed. If you only have the TurnKey auto security updates enabled and don't do any or many manual upgrades, then old unneeded packages don't tend to accumulate much at all. Even when they do, most don't take up much space.

However there is one specific exception - old kernels. Old kernels often take up hundreds of megabytes, so if your server has been running for a while, cleaning old kernels can free some significant space.

By default, the system will keep the most recent kernel and the previous one - just in case. So it is recommended that to maximize the space cleaned, do a reboot first. Note that if you have completely run out of space, it's a good idea to clean a bit of space before rebooting. Generally your system should reboot successfully even if it has no free space, however there are edge cases where it may not - so just in case!

Then remove redundant packages like this:

apt autoremove

Note that generally that is safe, however you should always look at the packages that will be removed. The system should warn you if important packages will be removed, but it always pays to check. If you see a particularly large number of packages listed and/or anything that you are sure you need, it's best to investigate further before removing them.

Vacuum the journal

These days, the journal is the system logger. By default it will take up to 20% of your root volume, to a maximum of 4GB. Unless you need to investigate historical issues, clearing the older log entries is safe. The 2 most straight forward ways to "vacuum" the journal are via size or time:

journalctl --vacuum-size=SIZE
journalctl --vacuum-time=TIME

Where SIZE & TIME are (perhaps obviously) the size or time. You can see the journalctl doc page for full info, but I'll mention the most useful ones here. E.g. to reduce to the specific size of 1GB & 128MB respectively & older than 2 weeks & 3 days respectively:

journalctl --vacuum-size=1G
journalctl --vacuum-size=128M
journalctl --vacuum-time=2w
journalctl --vacuum-time=3d

Permanently reduce disk usage

While not necessarily problematic, these do have wider implications than the other methods. So generally they are a off. I'll cover the downside and leave you to decide whether that's the path you want to take.

Make apt always remove new deb files are package install

DSELECT::Clean "always";

APT::Keep-Downloaded-Packages "false";

Binary::apt::APT::keep-downloaded-packages "false";

SystemMaxUse=SIZE
MaxRetentionSec=TIME

systemctl restart systemd-journald

apt update
apt install -y ncdu

ncdu /