All of lore.kernel.org
 help / color / mirror / Atom feed
From: Duncan <1i5t5.duncan@cox.net>
To: linux-btrfs@vger.kernel.org
Subject: Re: RAID1, SSD+non-SSD
Date: Sun, 8 Feb 2015 03:51:54 +0000 (UTC)	[thread overview]
Message-ID: <pan$cd5af$3b6c02fa$1b720ab9$26472039@cox.net> (raw)
In-Reply-To: CAPn+qJhHSj6Jfx8U=-cjN-d0547+L2fGVBpq0SJaDaZ8wEFtuw@mail.gmail.com

Brian B posted on Sat, 07 Feb 2015 21:41:08 -0500 as excerpted:

>  Sounds like it makes more
> sense to simply do backups to the slower drive and manually restore from
> those if I ever have a checksum error.
> 
> My main goal here was protection from undetectable sector corruption
> ("bitrot" etc.) without having to halve my SSD, but on btrfs I suppose
> it's impossible for bitrot errors to creep into backups, because I'd get
> a checksum error before that happened right?  Then I could just restore
> it from a previous backup.

Well, /as/ the bitrot happened, but you couldn't really do a backup of 
the bitrotted file, because you're correct, you'd get checksum errors due 
to the bitrot and btrfs wouldn't even let you access the file to back it 
up again, which in turn would mean it's time to restore at least that 
file from backup...

So yes, that plan does make sense to me. =:^)

BTW, it's worth noting the btrfs send/receive feature.  If both the ssd 
and the spinning rust backup are btrfs, send/receive should be an 
extremely efficient way to do the backups.  =:^)

Tho it may be worth keeping a more conventionally maintained second-level 
backup that's /not/ on btrfs as well, depending on how critical you 
consider that data.  While btrfs is stabilizing reasonably well now, it's 
not entirely stable yet and probably won't be for, let's say another 
year, and at least here, I really do sleep better knowing I have a non-
btrfs backup available as well.  You could manually checksum it, either 
in whole or in part, to be sure of detecting rot there, tho I've not done 
so here, figuring if I could survive decades without it before btrfs, I 
can survive another few years with it as a second backup.

Given the cost of SSD vs. spinning-rust, if all your data fits on the 
SSD, you should be able to do multiple levels of backup on spinning rust 
without breaking the bank.

(FWIW, altho as I mentioned earlier I have dual SSD btrfs raid1, I do 
still keep my media on spinning rust, NOT on SSD.  So I can't say all my 
data fits on SSD, here, or rather, it might, but that's not how I've set 
it up.  But as it happens the media files are both larger and less 
critical in terms of access speed, so spinning rust for them actually 
works out very well for me.)

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman


  reply	other threads:[~2015-02-08  3:52 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-02-06 20:01 RAID1, SSD+non-SSD Brian B
2015-02-07  0:23 ` Chris Murphy
2015-02-07 18:06   ` Kai Krakow
2015-02-08  3:31     ` Duncan
2015-02-07  6:39 ` Duncan
2015-02-07 12:42   ` RAID1, SSD+non-SSD (RAID 5/6 question) Ed Tomlinson
2015-02-08  3:18     ` Duncan
2015-02-08  2:41   ` RAID1, SSD+non-SSD Brian B
2015-02-08  3:51     ` Duncan [this message]
2015-02-07 17:28 ` Kyle Manna

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='pan$cd5af$3b6c02fa$1b720ab9$26472039@cox.net' \
    --to=1i5t5.duncan@cox.net \
    --cc=linux-btrfs@vger.kernel.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.