What defines a file system?

Borg’s documentation mentions an option that can be used when creating backups:

`-x` , `--one-file-system` stay in the same file system and do not store mount points of other file systems

What exactly does this mean?

Various parts of my system are mounted from different partitions or volumes.

$ lsblk --fs
NAME                                          FSTYPE      LABEL UUID     FSAVAIL FSUSE% MOUNTPOINT
sda                                                                                                     
├─sda1                                        vfat              [UUID]    181.7M     9% /boot/efi
├─sda2                                        ext4              [UUID]    712.4M    20% /boot
└─sda3                                        crypto_LUKS       [UUID]                  
  └─luks-[...]                                LVM2_member       [UUID]                
    ├─[system]-root                             ext4            [UUID]     11.5G    71% /
    ├─[system]-data                             ext4            [UUID]    222.1G    73% /media/data
    └─[system]-home                             ext4            [UUID]     55.4G    38% /home

Would they get backed up or not with that option? I get that it would be desirable to omit external drives or network mounts from backups.

It means Borg will only backup data that is on the same filesystem as the PATH you pass to it, and will ignore any directories that have been statically or dynamically mounted to that filesystem.

If you have a ‘/’ filesystem, have mounted ‘/home’ and ‘/data’ to it, invoke Borg with the --one-file-system option, and specify ‘/’ as the PATH, then the contents of /home and /data will not be added to the backup.

If you want to backup ‘/’ and ‘/home’ and ‘/data’ (but not anything else that has been mounted) then specify just those PATHs (separated by spaces) when you invoke Borg:

$ borg create --one-file-system path/to/myBackup / /home /data

3 Likes

Thanks! Can’t believe I didn’t think of that…

So that means /boot and /boot/efi also need to be specified for a complete backup. Does the latter’s FSTYPE being vfat cause any problem?

If you have a lot of filesystems mounted you might want to approach it from the other direction. Consider using --exclude instead.

$ borg create --exclude 'pp:/media' path/to/myBackup /

That would backup everything except the media directory (where Ubuntu, at least, mounts removable storage by default).

‘pp’ is a path pattern. You can read more about patterns here:
https://borgbackup.readthedocs.io/en/stable/usage/help.html

If you want to exclude several directories from the backup, you can use --exclude-from to specify a file — inside of which you simply have one pattern per line.

Borg uses standard system calls for reading and writing data, so as long as you are able to interact with those files, Borg will be able to as well. Apart from the usual permissions caveat, VFAT shouldn’t pose a problem.

PS: If you’re looking to backup EFI partitions as well, then I get the impression you want to create some sort of fully bootable/recoverable backup? I don’t think that is what Borg was designed to do, and I don’t know how well that would work. If that is, indeed, your goal, then I would strongly suggest that you grab some spare disks and test your recovery process to make sure it actually works.

2 Likes

Unfortunately I have my data volume mounted at /media/data. For future reference, what would be a better mount point to use?

I just checked and on Fedora 30, removable storage is getting mounted at /run/media/[USERNAME]/. But Veracrypt mounts volumes at /media/.

Maybe the approach of including mount points and using --one-file-system is more foolproof.

You can mount something like a /data filesystem anywhere that you find convenient. Depends on the nature of the data, and whether or not any other users/programs on your system need access to it.

You can also do something like this:

$ borg create --exclude 'pp:/media' path/to/myBackup / /media/data

…which excludes everything in the /media directory by default, then specifically includes the one subdirectory that you want.

I thought this thread was gonna discuss the merits of a block device, vs distributed file system, vs virtual devices, and networks/remotes etc

but the borg stuff looks super cool

Up until now /media/data was convenient. :smiley: I use it for all kinds of non-OS specific stuff, like personal files, projects, VMs, movies, music, etc. It is a vestige of dual-boot days, where I wanted to access this content from either OS.

Programs do need access to it, for example a music player that watches the music directory.

Additionally, I was planning on excluding the movies directory inside /media/data as it is really large and not so important.

Yeah, it does. I already read the documentation once, but it usually takes me a couple of iterations with practice in between before I really understand. Thanks to @level1 for sharing expertise.

1 Like

After thinking about it some more, I think it is more robust to use --one-file-system to exclude all other filesystems, and then explicitly include the mounts I want.

My reasoning is that the explicit inclusions are completely predictable.

If using the exclusion approach, I have to anticipate where the system might mount temporary filesystems to exclude them, and it’s clear this isn’t standardized or consistent behavior.

Does this make sense?

Sounds logical.

The great thing about software is that you can usually try something, run with it for a while, and if it comes up short you can tweak the approach or try something different.

At the end of the day, it’s your system, so you’re the only one that can weigh up all the factors and pick the option most suitable to your needs. Your opinion is the only one that (really) matters.

May the Borg serve you well… or you them (as the case may be). :wink:

Thanks. :wink:

I don’t put much stock in opinions, including my own. For a given goal and initial condition, it should be possible to assess the options objectively. I’m 95% confident Seven of Nine would agree. :smile: Feel free to disagree!

Next step is optimizing compression settings: