Meaning of Crossing filesystem boundaries, --one-file-system, etc

Question

I'm planning to use rsnapshot to backup my whole Linux system, though I'm confused by -x option (same of one_fs in rsnapshot.conf). The man page says:

-x one filesystem, don't cross partitions within each backup point

I understand it's not a specific rsnapshot option since rsync, cp, tar and other commands provide this feature as well.

Does file system boundaries refers to different partitions? Different mount points? And what does it mean to don't "cross" them?

Back to my case, I read many people suggesting to use -x with rsnapshot, but I'm wondering if doing so is not going to compromise the completeness of my backup. I want to backup everything under /, including /boot and /home, which reside on dedicated partitions of the same disk, while at the same time I don't want to backup files and directories not strictly belonging to my system, like /mnt, /media, etc.

Executing mount command on my system gives the following output. Pratically, using rsnapshot -x, what will be included and what will be left out?

/dev/sda7 on / type ext4 (rw,errors=remount-ro)
proc on /proc type proc (rw,noexec,nosuid,nodev)
sysfs on /sys type sysfs (rw,noexec,nosuid,nodev)
none on /sys/fs/fuse/connections type fusectl (rw)
none on /sys/kernel/debug type debugfs (rw)
none on /sys/kernel/security type securityfs (rw)
udev on /dev type devtmpfs (rw,mode=0755)
devpts on /dev/pts type devpts (rw,noexec,nosuid,gid=5,mode=0620)
tmpfs on /tmp type tmpfs (rw,noexec,nosuid)
tmpfs on /run type tmpfs (rw,noexec,nosuid,size=10%,mode=0755)
none on /run/lock type tmpfs (rw,noexec,nosuid,nodev,size=5242880)
none on /run/shm type tmpfs (rw,nosuid,nodev)
/dev/sda6 on /boot type ext3 (rw)
/dev/sda8 on /home type ext4 (rw)
binfmt_misc on /proc/sys/fs/binfmt_misc type binfmt_misc (rw,noexec,nosuid,nodev)
gvfs-fuse-daemon on /home/myuser/.gvfs type fuse.gvfs-fuse-daemon (rw,nosuid,nodev,user=myuser)

Solution 1

“Do not cross filesystem boundaries” means “do not look inside mount points”. A boundary between filesystems is a mount point. Effectively, this means “only act on the specified partition”, except that not all filesystems are on a partition. See What mount points exist on a typical Linux system?

When you make a backup, you should avoid a number of filesystems, in particular:

• remote filesystems (NFS, Samba, SSHFS, …);
• filesystems whose content is generated on the fly from runtime data (/proc, /sys, …);
• filesystems which are a view of another part of the directory tree (bindfs, avfs, …);
• in-memory filesystems containing data that is only valid until the next reboot (/tmp, /dev/shm, …);
• removable media which may or may not be present at any given time and aren't part of the system proper.

The filesystems to back up are only the ones that correspond to on-disk storage. Many systems have only a single such filesystem, mounted on the root directory /. You can tell which filesystems correspond to on-disk storage because their source (first column titled “Filesystem” of the df output, first column before on of the mount output) is a disk volume (a PC-style partition such as /dev/sda1, an LVM logical volume such as /dev/mapper/mygroup-mylogicalvolume, …).

There are a few subtleties that can make determining which filesystems to back up harder than just looking at the source to see if it's on-disk:

• Removable volumes shouldn't get backed up, even though they are on-disk.
• Linux allows the same filesystem (or parts thereof) to be mounted at multiple locations, with mount --bind; only one of them should be backed up.
• It can be difficult to enumerate all on-disk volumes: there are encrypted volumes, distributed storage volumes, etc.

On your system, the filesystems to back up are /dev/sda7 mounted on /, /dev/sda6 mounted on /boot and /dev/sda8 mounted on /home. So you should tell rsnapshot to back up those three directories. You should almost always use the -x option with rsnapshot.

Solution 2

To simplify things, let's just consider two partitions. Assume that running mount actually produced the following output:

/dev/sda1 on / type ext4 (rw,errors=remount-ro)
/dev/sda2 on /home type ext4 (rw)

This is, of course, utterly unrealistic (/dev wouldn't be populated, tons of stuff relies on sysfsand procfs, etc). Let's just ignore that.

Crossing a filesystem boundary means changing into a directory in which the underlying filesystem (which usually corresponds to the underlying partition) is different. Usually when someone talks about crossing a filesystem boundary, they're talking about it in the context of traversing the directory tree either down or up.

As an example of what I mean, take git. To figure out if a directory is a Git repository, git first checks to see if there is a folder called ".git" in the current working directory. If there is, it's a Git repository. If there isn't, git will perform the same check on the parent of the current directory, and so on and so forth. By default, Git will check like this all the way up until the filesystem boundary (or once it's reached /), at which point it will give up and assume that the current working directory is not, in fact, a Git repository.

Say you run git status in ~/Desktop. Git checks to see if there's a ~/Desktop/.git directory... nope. Git will now check the parent directory: is there a ~/.git? Nope. Here's the point where filesystem boundaries come into play: since /home is a separate partition, instead of checking for /home/.git, git will give up, print a warning to the console, and assume that the current working directory isn't a Git repository. It has refused to cross filesystem boundaries.