Server Fault is a question and answer site for system and network administrators. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I'm backing up a linux server and storing it on some other server. I started off with a simple

rsync -aPh --del /mnt/backup

Then someone pointed out that I shouldn't back up /proc, since you don't want to restore the /proc of one server on another.

Is there anything else that I should / shouldn't include? What about /sys?

share|improve this question

10 Answers 10

up vote 18 down vote accepted

This really depends on how you are going to restore your system. If you will rebuild then you only need the configuration/data files for your services (eg: /etc, /opt, /var, /home)

If you are after a full system restore, then it you could omit /proc, /boot & /dev. Then you can install the minimum OS from your boot media and then restore your system via your backup.

Of course, the best backup is one that has been tested and verified.

So omit what you don't think you need, try to restore in a VM and verify you can get back your system using this data.

share|improve this answer
Don't omit /boot entirely -- you might need to compare old boot config with new boot config. Just be sure not to restore /boot except manually. – quack quixote Oct 15 '09 at 13:24
And exclude /sys as well... And to restore to bare metal, you'd better exclude /etc/udev/rules.d/ too. – wazoox Oct 15 '09 at 13:31
also lost+found which for the file system, /mnt and /media to not copy any mounted device – blade May 19 '15 at 14:26

Both /proc and /sys are virtual filesystems which reflect the state of the system, and allow you to change several runtime parameters (and sometimes do more dangerous things, like directly writing to the memory or to a device). You should never backup or restore them.

In most modern distributions, /dev is dynamically created at boot (it is a memory filesystem filled by udev and friends). There is no point in backing it up, and attempting to restore it is futile. However, if your distribution is configured to use a static /dev, this does not apply (check /proc/mounts, if /dev is a tmpfs it is a memory filesystem).

There are other filesystems you should not back up; usbfs (usually at /proc/bus/usb, if mounted at all), debugfs (supposed to be at /sys/kernel/debug if mounted at all, but some people put it somewhere else; you probably do not have this one), devpts (mounted at /dev/pts), other tmpfs instances (often found at /dev/shm, /var/run, /var/lock, and other places; backing them up and restoring them should be harmless but pointless, as their contents are lost on shutdown), and any remote filesystems or magic automounter directories (attempting to backup or restore them could end up in disaster, as you could end up backing up/restoring to a different machine). You should also be careful with /media and /mnt, as external devices (like a CD you forgot in the drive) could be found there, but you might also have used them on purpose to mount something which should be backed up.

Note that, other than mostly harmless tmpfs instances, network filesystems/automounters, and removable media, the filesystems you should not back up are all descendents of /dev, /proc, or /sys. If you have no network filesystems (or automounters), and no removable media, excluding /sys and /proc and rebooting after a restore (to wipe the tmpfs instances) should be enough.

share|improve this answer

See The Tao Of Backup, chapter 1.

share|improve this answer

Some of the special files in /proc and /sys confuse rsync. You don't want to back up mounted network filesystems either, usually. Sparse files can also cause problems.

Add -x to limit it to one file system. That avoids all the network file systems and /proc etc. However you then need to run one rsync for each file system you have mounted.

Add -S to handle sparse files sensibly.

share|improve this answer

You could achieve a total backup using sfdisk and dd. To backup the partition scheme of each hard drive, you'd use sfdisk like this:

sfdisk -d /dev/sda  > parttable_sda.part

To backup each partition you could use dd, like so:

dd if=/dev/sda1 of=devsda1.img

(keep in mind you're going to need to have a a lot of free space to write this file; so you may want to write it to an external media) Do that for each partition, one at a time, and back everything up.

Then, do restore on another computer you can do:

sfdisk /dev/sda < parttable_sda.part
dd if=devsda1.img of=/dev/sda1    # do this for each partition
share|improve this answer
WARNING: only do this if the partition is unmounted or mounted read-only. Dumping the raw contents of a partition while it is being written to can end up with a badly inconsistent filesystem on the backup (because blocks near the beginning of the filesystem are copied "earlier" than blocks near the end, and the filesystem algorighms do not expect this; you can avoid this problem if you can somehow do an atomic snapshot of the filesystem). fsck will not help you, since its algorithms also depend on the order the filesystem writes to the disk. – CesarB Oct 16 '09 at 20:42

/boot, /dev and /proc are quite useless to backup -- though, if you know what you're doing you can backup /boot.

I would also not backup /lib, /media, /mnt, /sbin, /bin, /srv, /sys, or /tmp.

/usr is optional, depending on whether you have anything in /usr worth backup up. If I were you I"d worry most about backing up user's $HOMEs, /var, and /etc (for configuration files).

Again though, this really all depends on the type of backup you want to do. Is this a web server? Is this a personal computer? Is this a shell server with tons of directories under /home?

share|improve this answer
I'd like to restore by use cloning the backup onto a new machine – Rory Oct 15 '09 at 12:18
What do you mean by "cloning"? You could always just backup the raw partitions using dd and sfdisk sfdisk -d > partition_table.part dd if=/dev/sda1 of=dev.sda1.img (do this for each partition) then, on your new system: sfdisk /dev/sda < partition_table.part dd if=dev.sda1.img of=/dev/sda1 (for each partition, again) – Michael Pobega Oct 15 '09 at 14:03
Since the comment system doesn't like code tags, I posted another answer. – Michael Pobega Oct 15 '09 at 14:08

Basically, pseudo-filesystems (/proc, /sys, /dev/shm...) need not be backed up.

share|improve this answer

Instead of excluding, I usually only backup what I want. Including: /home /etc /var (except /var/log)

share|improve this answer

I generally make a habit of backing up everything on a system, even the stuff that I know for certain is useless to back up. It's simpler to set up and you can be 100% sure that you're going to get everything you do need included in the backup.

share|improve this answer
yes, but the follow up question is what do you rem0ove from your backup as unneeded? – Rory Oct 15 '09 at 12:16
To which I would respond: "nothing". – Le Comte du Merde-fou Oct 15 '09 at 12:44
True. You exclude it from the restore process, not the backup itself. But you probably still want to leave out /proc and /dev so as not to confuse poor little rsync. – T.J. Crowder Oct 15 '09 at 14:01
@mh, you would restore /proc/kcore, which is the memory of the original server? that sounds a bit silly... – Rory Oct 15 '09 at 15:02

I'm using an Ubuntu linux box as a testing server for website development, and for hosting a documentation wiki. Each night a crontab dumps the MySQL database into /var/www, and then all of /var/www is zipped up and replicated to the backup server. It's not ideal, but it's enough. I had to rebuild the server at one point, and all I really missed were the Apache and Samba configuration files.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.