Re: state of btrfs snapshot limitations?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Wow, thank to everyone for all that information, I'm going to have to
take some time to digest everything. :)

I just wanted to quickly say one thing: As Duncan surmised, I'm not
treating this as my primary backup, but more of an experimental add-on
feature.  The primary backup goes to an ext4 partition that is then
rsynced to a 'current' btrfs subvolume, the latter is what I'm taking
snapshots of.  These both share a RAID 1+0 enclosure.  The partitions
are oversized, 3TB each, so based on this thread that size is something
to watch out for if I use up a lot more of the space.

For other backups I've also got a Amazon Glacier based backup (large
"offsite" but painful to recover with) via Arq, and an Apple
TimeCapsule backup (easy point-and-click restore for a single item, but
damn flakey and painfully slow for anything complicated).  So I'm not
trusting any one device or scheme.

As an aside, one of the things I loved about reading the Plan 9 papers
was their description of their three-tier storage.  Where they had "infinite"
long term storage via a WORM array, SCSI disks on big servers for the
"cache," and then local disk / memory for the files they were working
on right at that moment (http://doc.cat-v.org/plan_9/misc/cw/cw.pdf).

I do like the idea of periodic "copy to a clean disk" and "mkfs of the
old disk" scheme instead of a complicated in-place rebuilding and/or
defragmentation, I think I have enough capacity that I will probably
try that if/when it becomes necessary.

I've got to read up a bit more on subvolumes, I am missing some
context from the warnings given by Chris regarding per-subvolume
options.



[Index of Archives]     [Linux Filesystem Development]     [Linux NFS]     [Linux NILFS]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux