1 |
On Oct 28, 2014 12:38 AM, "Rich Freeman" <rich0@g.o> wrote: |
2 |
> |
3 |
> On Mon, Oct 27, 2014 at 1:23 PM, Volker Armin Hemmann |
4 |
> <volkerarmin@××××××××××.com> wrote: |
5 |
> > Am 27.10.2014 um 16:36 schrieb Rich Freeman: |
6 |
> >> and a boot |
7 |
> >> partition as I don't think grub supports it - it could be a bit of a |
8 |
> >> PITA for a single-drive system. |
9 |
> > |
10 |
> > nope. But I don't see any reason to use zfs with a single drive either. |
11 |
> |
12 |
> True, not needing to use FUSE does simplify things, but I don't |
13 |
> believe that grub supports zfs, so you would need a boot partition. |
14 |
> Granted, a newer laptop would need that for EFI anyway. |
15 |
> |
16 |
> > |
17 |
> >> However, it is probably more mature |
18 |
> >> than btrfs overall, and it certainly supports send. |
19 |
> > |
20 |
> > and if your send stream is corrupted, your data is gone. That is why I |
21 |
> > prefer cp&tar to backup my zfs data tank. |
22 |
> > |
23 |
> |
24 |
> If you ONLY save the send stream without checking it, then you're |
25 |
> right that you're depending on its integrity. I'd certainly be |
26 |
> nervous about doing that with btrfs, probably less so with zfs but I |
27 |
> can't really vouch for it. I don't know what ability either |
28 |
> filesystem gives you to verify a send stream in isolation. |
29 |
> |
30 |
> Now, what you could do is receive the send stream into a replica |
31 |
> filesystem on the far end, and not consider the backup successful |
32 |
> until this is done. That would look like a btrfs-to-btrfs rsync |
33 |
> operation, but it would be much more efficient in terms of IO. It |
34 |
> would require a daemon on the far end to run the receive operation and |
35 |
> report back status, vs just dumping the files via scp, etc. |
36 |
> |
37 |
> Does anybody know if either btrfs or zfs send includes checksums? I |
38 |
> know the data is checksummed on disk, but I have no idea if it is |
39 |
> protected in this way while serialized. |
40 |
> |
41 |
|
42 |
zfs has checksum for the send stream. That's why you can send the stream to |
43 |
a file, and fail to import the file sometime later if something changes in |
44 |
that file. |
45 |
|
46 |
So, always do a filesystem replication. Don't just save the send stream. |
47 |
Have the replica make the snapshots visible in poolroot/.zfs, and backup |
48 |
the whole filesystem using a deduping backup system. |
49 |
|
50 |
Rgds, |
51 |
-- |