On Wed, Aug 17, 2016 at 09:38:50AM -0400, Gene Heskett wrote: > This last link is from 2008. It does seem to be difficult, and only > accomplishable by a full dump, repartition and recovery. The latter > would not be a problem if a regular backup is being done. But I've no > knowldge about how tar handles an xfs filesystem. Ack the man page, its > agnostic as there is zero mention of the filesytem in use. > > I use amanda as the tar manager here but my nightly backups are rather > tiny compared to 13Tb, rarely exceeding 20 gigabytes for 4 machines. > > With my wrapper script, I can lose the main drive, and put in a new one, > and have it recovered to its state as of about 3am this morning in 4 or > 5 hours. Any transactions after that time would be lost but 98% of that > is email traffic. Non-commercial IOW. Using commodity 1T drives, I have > the last 30 days worth of amanda backups on one of them using virtual > tapes. Unlike a tape drive that always has to spend the winter holidays > in Oklahoma City getting rebuilt, I have random (fast) access to my > data. That drive is now about 4 years old, has had 25 re-allocated > sectors for much of that time, less than 50 power ups, and shows 45% > usage in a df -h report right now. Whats not to like? :) > > What does zfs do for one that ext4 can't that makes it attractive to use?
ZFS has: - checksum of all data, so you can detect when you are reading data that wasn't what you wrote - if RAID is set up, correction of that data, including knowing which cop(ies) pass the checksum - built in snapshotting, faster and more efficient than LVM's version - built in send/receive - like dump, but with better than rsync efficiency - read and write caching for spinning disks can be done with SSDs, to provide a significant price/performance advantage for large storage. Of these, I guess the last one wouldn't be too interesting to you. -dsr-
