| 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 |
-- |
Archives