Is there any good reason to not use the tar command on the root directory for a full system backup? Alternatively, is there a better way to create a full copy of your Linux system?

  • What if a bit or two of the compressed archive is lost due to disk corruption? I've always wondered that. The bright side of using tar is that the permissions I believe will be retained as you'd hope. You still have to exclude /dev, /run, /var/run, and a variety of other files from the backup no matter how you do it. And if you want only one file out of the backup? which is my normal case for using backup data? I'd rather ask, why not rsync?
    – Lizardx
    Commented Dec 16, 2017 at 23:27
  • @Lizardx and why is it that you'd have to exclude /dev, /run, and /var/run? Just because they cannot be copied? I'm still new to Linux and trying to figure out this exact kind of stuff. Also, what is the difference between rsync and tar? Commented Dec 16, 2017 at 23:36
  • Those files are made live by the kernel when it boots the system, basically. You don't want to back them up because the kernel creates them and updates them during operation. rsync is rsync, and tar is tar, it's not even apples and oranges, it's grapes and watermelons. tar rolls the files into one big ball, and rsync syncs files. If you are unclear, take an installed linux system, boot that machine with a live cd, then look at what is inside /dev, /run/ var/run, etc in the non running system. Also /sys, which is all made by the kernel during its operation. And /proc Not all files are static.
    – Lizardx
    Commented Dec 17, 2017 at 0:03
  • @SomeDudeFromtheInternet It's complicated. Sometimes, the root partition will contain a /dev with a minimal set of essential device files required for boot. You must copy these. The complication is that, after booting, it is common to mount a new directory over the one on disk. This contains more than you need.
    – John1024
    Commented Dec 17, 2017 at 0:12
  • It is in linux, and I have done it in complement to having other type of backups as an additional measure. Commented Dec 17, 2017 at 0:24

1 Answer 1


Whether a tar based backup works for you depends on what kind of meta data you like to archive and what tar implementation you are using.

GNU tar recently added support for Linux ACLs, but the support is defective and it may be that files are extracted with ACLs that are not in the archive, but have been inherited from the parent directory. This may give access to users that should not have this access.

Similar problems apply to the SELinux support in GNU tar.

If you do not rely on this kind of meta data and if you do not plan to make incremental backups, you may use GNU tar.

BTW: the most recent version of star (in schilytools) added SELinux support.

People who believe that it is possible to use GNU tar for incremental backups, should run this script to verify that it does not work. A related bug report has been send to the GNU tar maintainers in September 2004, in 2011 and in 2016, this bug is known since 14 years:

if [ "$gtar" ]; then
    # Permit: gtar=/tmp/tar-1.30/src/tar sh gnutarfail.sh
    GT=`"$gtar" --help 2> /dev/null | grep GNU`
    GT=`gtar --help 2> /dev/null | grep GNU`
    if [ "$GT" ]; then
            # Some systems have "gtar" installed as "tar"
            GT=`tar --help 2> /dev/null | grep GNU`
            if [ "$GT" ]; then
if [ -z "$GT" ]; then
    echo No gtar found
    exit 1
echo gtar installed as $gtar
# Preparation complete

cd /tmp
mkdir test.$$
cd test.$$

set -x

mkdir test
mkdir test/dir1
mkdir test/dir2

echo dir1-file > test/dir1/dir1-file
echo dir2-file > test/dir2/dir2-file

$gtar -g/tmp/test.$$/listed-incr -c -f /tmp/test.$$/full.tar test

rm -rf test/dir2
mv test/dir1 test/dir2

$gtar -g/tmp/test.$$/listed-incr -c -f /tmp/test.$$/incremental.tar test

mv test orig

$gtar -x -g/dev/null -f /tmp/test.$$/full.tar
$gtar -x -g/dev/null -f /tmp/test.$$/incremental.tar
  • Is it the mv test orig ? You make it sound like it does not work at all.
    – user373503
    Commented Feb 16, 2020 at 22:43
  • 2
    It doesn't work for most cases with renamed dirs because gtar uses an archive format that does not track file identities (inode numbers) and because gtar permits to make incremental backups that cross mount points. star on the other side tracks inode numbers in the archive and creates a data base with original and current inode numbers during the restore. This allows star to reliably detect renames and to do the right things during restore. star incremental archives hold all needed meta data but are smaller that gtar archives (gtar archives the whole tree behind touched dirs)
    – schily
    Commented Feb 17, 2020 at 10:55

You must log in to answer this question.

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