I'm looking for a list which paths/files are safe to exclude for a full system/home backup.

Considering that I have a list of installed packages.

  • /home/*/.thumbnails
  • /home/*/.cache
  • /home/*/.mozilla/firefox/*.default/Cache
  • /home/*/.mozilla/firefox/*.default/OfflineCache
  • /home/*/.local/share/Trash
  • /home/*/.gvfs/

  • /tmp/

  • /var/tmp/
  • not real folders but can cause severe problems when 'restoring'
    • /dev
    • /proc
    • /sys

What about...

  • /var/ in general?
  • /var/backups/ - can get quite large
  • /var/log/ - does not require much space and can help for later comparison
  • /lost+found/
  • This is an (very) related answer worth looking at (assuming this isn't closed as a duplicate) : askubuntu.com/questions/5596/how-to-clean-caches-in-my-homedir/…
    – Scaine
    Mar 3, 2011 at 21:44
  • I am not sure about /home/*/.local/share/Trash. I already restored files from trash folder on backup. It was a mistaken deletion, noticed and undone after I made backups - and on restoring backups files were still in trash. Jan 29, 2017 at 11:59
  • ~/.local/share/Trash/* seems to be universal, but is by user.
    – SDsolar
    Jul 30, 2017 at 5:01
  • Note that this was posted in 2011. Your mileage may vary in 2017.
    – SDsolar
    Jul 30, 2017 at 5:08

3 Answers 3


When I rsync my system to a backup partition, I exclude these:

--exclude=/dev/* \
--exclude=/home/*/.gvfs \
--exclude=/home/*/.mozilla/firefox/*/Cache \
--exclude=/home/*/.cache/chromium \
--exclude=/home/*/.thumbnails \
--exclude=/media/* \
--exclude=/mnt/* \
--exclude=/proc/* \
--exclude=/sys/* \
--exclude=/tmp/* \
--exclude=/home/*/.local/share/Trash \
--exclude=/etc/fstab \
--exclude=/var/run/* \
--exclude=/var/lock/* \
--exclude=/lib/modules/*/volatile/.mounted \
--exclude=/var/cache/apt/archives/* \

This way I am able to boot into the backup partition the same way I can boot to the original one.

So to sum up, I would suggest

  • not excluding /{dev,proc,media,...} themselves, just their contents

  • excluding /var/{run,lock}, and especially the big /var/cache/apt/archives/

  • 2
    You want to exclude ALL of /dev.
    – psusi
    Mar 1, 2011 at 3:33
  • 2
    I would recommend using the -x option with rsync for backups. That way, it will not cross filesystem boundaries, which will exclude things like /dev /proc /sys /mnt and /media. You still have to exclude /home/*/.gvfs.
    – Azendale
    Jul 7, 2011 at 16:04
  • 3
    @Azendale: might be. On the other hand, when you use something like --exclude=/proc/*, it will keep the directory /proc on the backup (which is needed if you want to boot the mirror), but not the contents of it.
    – arrange
    Jul 8, 2011 at 16:35
  • 2
    maybe a naive question, but why /etc/fstab has been excluded as well?
    – Paolo
    Dec 11, 2013 at 21:33
  • 1
    The huge files are /var/log/kern* and var/log/messages* - are they safe to exclude?
    – SDsolar
    Aug 13, 2017 at 23:25

I'll recomend to exclude all /usr (except fort /usr/local/) and have a backup of dpkg --get-selections

In my opinion a Full backup isn't really usefull. I rather prefer backup data and preferences and then restore packages from the official repositories.

But is my preference...

/usr contains mainly static binary content from distribution packages. Reinstalling a package will restore /usr contents. Also /bin and /sbin contains binaries from distribution packages.

/usr/local contains manually installed packages (out of distribuition packages). so this is worth to backup.

  • 2
    Very interesting approach. It will yield a significantly smaller backup, but require way more trouble (time, internet bandwidth) when restoring. A compromise that may be worth in some use cases. Questions: how about /lib, the same applies? And how do you restore such package selection?
    – MestreLion
    Apr 4, 2013 at 11:44
  • 2
    Yes, I think you can also exclude /lib. I'd add also that instead of dpkg --get-selections it's maybe better to use apt-mark, as said here: askubuntu.com/questions/101931/…
    – gerlos
    May 4, 2015 at 14:53

I also read all of the answers and all the other related questions when I was configuring my full system backup.

My 2 cents would be not to exclude anything but only when you are doing a full system backup of an offline system.

Let me elaborate now: If you backing up the system from within itself, then you may exclude some directories as others have mentioned but this is not a good way in my opinion as it can introduce some bugs later on when restoring the system. For example, if you exclude /tmp directory, then after restoring it, /tmp won't be there and system will create one and this can have stuck login screens due to chmod & chown issues on /tmp. Also not backing up ~/.cache directory can result in breaking up database cache of Ubuntu Software Centre.

What I do is use a live CD and use LuckyBackup and backup the entire system without omitting anything. Now when restoring, I chose 'delete files not present in the source'. This way you will have an entire system snapshot restored exactly to the state when you created the backup (kinda like snapshotting a VM).

  • 2
    Many files are not supposed to be saved because they are not real files, but rather pseudo-files. You may want want to save caches, but don't save the contents of /proc, /dev, sys. Their contents are created on boot. Aug 23, 2014 at 0:07
  • 1
    @TeresaeJunior When this approach is followed and the backup is done from an offline system, the contents of these not-real files are already empty. Aug 26, 2014 at 12:45
  • Yes, you're right, sorry! I didn't pay attention to the LiveCD you mentioned. Aug 26, 2014 at 16:33
  • I'm afraid these systems have to run 24x7 so don't have that luxury. I have a great exclude list but keep getting hung up on 4G /var/log/kern* and /var/log/messages* - I would like to exclude them but nobody talks to that. How about excluding /var/log/* totally?
    – SDsolar
    Aug 13, 2017 at 23:28

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .