On 2017-10-21 14:07, Adam Borowski wrote:
On Sat, Oct 21, 2017 at 01:46:06PM +0200, Lentes, Bernd wrote:
----- Am 21. Okt 2017 um 4:31 schrieb Duncan 1i5t5.duncan@xxxxxxx:
Lentes, Bernd posted on Fri, 20 Oct 2017 20:40:15 +0200 as excerpted:
Is it generally possible to restore a btrfs partition from a tape backup
?
I'm just starting, and I'm asking myself. What is about the subvolumes ?
This information isn't stored in files, but in the fs ? This is not on a
file-based backup on a tape.
Yes it's possible to restore a btrfs partition from tape backup, /if/ you
backed up the partition itself, not just the files on top of it.
Which is usually a quite bad idea: unless you shut down (or remount ro) the
filesystem in question, the data _will_ be corrupted, and in the case of
btrfs, this kind of corruption tends to be fatal. You also back up all the
unused space (trim greatly recommended), and the backup process takes ages
as it needs to read everything.
An efficient block-level backup of btrfs _would_ be possible as it can
nicely enumerate blocks touched since generation X, but AFAIK no one wrote
such a program yet. It'd be also corruption free if done in two passes:
first a racey copy, fsfreeze(), copy of just newest updates.
I think partimage _might_ have BTRFS support by now, and if so, that's
likely to be the best you can get for quite some time.
Otherwise, as you deduce, you get the files, but not the snapshot history
or relationship, nor the subvolumes, which will look to normal file-level
backup software (that is, backup software not designed with btrfs-
specifics like subvolumes, which if it did, would likely use btrfs send/
receive at least optionally) like normal directories.
If the backup software does incrementals well, this is not as bad as it
sounds. While rsync takes half an hour just to stat() a typical small piece
spinning rust (obviously depending on # of files), that's still in the
acceptable range. That backup software can be then be told to back every
snapshot in turn. You still lose reflinks between unrelated subvolumes but
those tend to be quite rare -- and you can re-dedupe.
i apprehend that i have just a file based backup. We use EMC Networker
(version 8.1 or 8.2), and from what i read in the net i think it does not
support BTRFS. So i have to reinstall, which is maybe not the worst,
because i'm thinking about using SLES 11 SP3.
What i know now is that i can't rely on our EMC backup.
What would you propose to backup a complete btrfs partition
(https://btrfs.wiki.kernel.org/index.php/Incremental_Backup) ?
We have a NAS with propable enough space, and the servers aren't used
heavily over night. So using one of the mentioned tools in a cronjob over
night is possible.
Which tool do you recommend ?
It depends on what you use subvolumes for.
And this is the important part. If you're just using them to segregate
workloads (like I do), or exclude things from snapshots (like I used to
do when I was using snapshots for backups), then any old backup program
is fine as long as you know enough to replicate the subvolume layout
when extracting (if you need the same layout that is). I'm actually
working on a script to automate this for file-level backups (stuff like
Amanda, Bareos, and borgbackup), but I don't have anything ready to
share yet.>
While a simple file-base backup may be inadequate for the general case, for
most actual uses it works well or at least well enough. Only if you're
doing something special, bothering with the complexity might be worth it.
SLES (and OpenSUSE in general) does do something special though, they
use subvolumes and qgroups to replicate multiple independent partitions
(which is a serious pain in the arse), and they have snapshotting with
snapper by default as well. On OpenSUSE at least you can dispense with
all that crap by telling the installer to not enable snapshot support,
not sure about SLES though.
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
