On 2017-03-25 23:00, J. Hart wrote:
I have a Btrfs filesystem on a backup server.  This filesystem has a
directory to hold backups for filesystems from remote machines.  In this
directory is a subdirectory for each machine.  Under each machine
subdirectory is one directory for each filesystem (ex /boot, /home, etc)
on that machine.  In each filesystem subdirectory are incremental
snapshot subvolumes for that filesystem.  The scheme is something like
this:

<top>/backup/<machine>/<filesystem>/<many snapshot subvolumes>

I'd like to try to back up (duplicate) the file server filesystem
containing these snapshot subvolumes for each remote machine.  The
problem is that I don't think I can use send/receive to do this. "Btrfs
send" requires "read-only" snapshots, and snapshots are not recursive as
yet.  I think there are too many subvolumes which change too often to
make doing this without recursion practical.

Any thoughts would be most appreciated.
In general, I would tend to agree with everyone else so far if you have to keep your current setup. Use rsync with the --inplace option to send data to a staging location, then snapshot that staging location to do the actual backup.

Now, that said, I could probably give some more specific advice if I had a bit more info on how you're actually storing the backups. There are three general ways you can do this with BTRFS and subvolumes:
1. Send/receive of snapshots from the system being backed up.
2. Use some other software to transfer the data into a staging location on the backup server, then snapshot that. 3. Use some other software to transfer the data, and have it handle snapshots instead of using BTRFS, possibly having it create subvolumes instead of directories at the top level for each system.

Of the three, I would generally recommend method 2, as it doesn't require the remote system to be using BTRFS, and generally scales pretty well, and it also amounts to essentially what people are recommending you do to backup your backup server.

On the note of needing read-only snapshots, in both cases 1 and 2, your snapshots should be read-only on the server (method 1 mandates it, method 2 makes it easy). In case 3, the snapshots should ideally be getting marked read-only some other way. Having backups be writable is a bad idea, it leads to too many opportunities for software to screw things up, and makes it impossible to tell if you just accidentally messed things up, or something went wrong in your backup system or hardware.
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to