public inbox for gentoo-user@lists.gentoo.org
 help / color / mirror / Atom feed
From: Rich Freeman <rich0@gentoo.org>
To: gentoo-user@lists.gentoo.org
Subject: Re: [gentoo-user] Safeguarding strategies against SSD data loss
Date: Mon, 27 Oct 2014 13:37:24 -0400	[thread overview]
Message-ID: <CAGfcS_m1CUbj=vEpPAiNoSYK7-FD-3vULnpfT-8+8r_MgXMrLQ@mail.gmail.com> (raw)
In-Reply-To: <544E7F83.4020303@googlemail.com>

On Mon, Oct 27, 2014 at 1:23 PM, Volker Armin Hemmann
<volkerarmin@googlemail.com> wrote:
> Am 27.10.2014 um 16:36 schrieb Rich Freeman:
>>  and a boot
>> partition as I don't think grub supports it - it could be a bit of a
>> PITA for a single-drive system.
>
> nope. But I don't see any reason to use zfs with a single drive either.

True, not needing to use FUSE does simplify things, but I don't
believe that grub supports zfs, so you would need a boot partition.
Granted, a newer laptop would need that for EFI anyway.

>
>>  However, it is probably more mature
>> than btrfs overall, and it certainly supports send.
>
> and if your send stream is corrupted, your data is gone. That is why I
> prefer cp&tar to backup my zfs data tank.
>

If you ONLY save the send stream without checking it, then you're
right that you're depending on its integrity.  I'd certainly be
nervous about doing that with btrfs, probably less so with zfs but I
can't really vouch for it.  I don't know what ability either
filesystem gives you to verify a send stream in isolation.

Now, what you could do is receive the send stream into a replica
filesystem on the far end, and not consider the backup successful
until this is done.  That would look like a btrfs-to-btrfs rsync
operation, but it would be much more efficient in terms of IO.  It
would require a daemon on the far end to run the receive operation and
report back status, vs just dumping the files via scp, etc.

Does anybody know if either btrfs or zfs send includes checksums?  I
know the data is checksummed on disk, but I have no idea if it is
protected in this way while serialized.

--
Rich


  reply	other threads:[~2014-10-27 17:37 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-10-27  9:24 [gentoo-user] Safeguarding strategies against SSD data loss Mick
2014-10-27 10:30 ` Alec Ten Harmsel
2014-10-27 11:11 ` Alan McKinnon
2014-10-27 13:13   ` Rich Freeman
2014-10-27 15:15     ` [gentoo-user] " James
2014-10-27 15:23       ` Mick
2014-10-27 15:22     ` [gentoo-user] " Mick
2014-10-27 15:36       ` Rich Freeman
2014-10-27 16:52         ` Pandu Poluan
2014-10-27 17:26           ` Volker Armin Hemmann
2014-10-27 17:30           ` Rich Freeman
2014-10-28  0:41             ` Pandu Poluan
2014-10-28  1:13               ` Rich Freeman
2014-10-28  3:45           ` Tom H
2014-10-27 17:23         ` Volker Armin Hemmann
2014-10-27 17:37           ` Rich Freeman [this message]
2014-10-28  0:56             ` Pandu Poluan
2014-10-28  3:49             ` Tom H
2014-10-27 17:20       ` Volker Armin Hemmann
2014-10-27 17:17     ` Volker Armin Hemmann
2014-10-27 12:27 ` Philip Webb
2014-10-27 14:12   ` [gentoo-user] Safeguarding strategies against SSD data loss : PS Philip Webb
2014-10-27 15:16   ` [gentoo-user] Safeguarding strategies against SSD data loss Mick

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAGfcS_m1CUbj=vEpPAiNoSYK7-FD-3vULnpfT-8+8r_MgXMrLQ@mail.gmail.com' \
    --to=rich0@gentoo.org \
    --cc=gentoo-user@lists.gentoo.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox