On Tue, Feb 8, 2011 at 6:53 AM, Jeff Klingner <klingner@xxxxxxxxxxxx> wrote:
> I'm planning a backup system for my home server and have run into a question I can't find answered in the mailing list archives or the wiki. Here's the plan:
>
> 1. Install system and valuable data on a 3-disk raid1 array (call the disks A, B, and C).
> 2. Remove disk C, put it offsite. ("offsite" is moderately time-consuming to get to.)
> 3a. Periodically, remove disk B, take it offsite, and retrieve disk C
> 3b. Insert disk C, which will be re-synced to gain any changes made since it was removed.
> 4. Repeat steps 3a and 3b indefinitely, alternating the roles of disks B and C.
>
> Thus I hope to get continuous protection against a single drive failure and protection back to the last offsite swap for corrupted or deleted data.
I went through a (probably much too) long discussion here on similar
(but more complex) ideas.
http://www.issociate.de/board/goto/2050886/Q:_LVM_over_RAID,_or_plain_disks?_A:%22Yes%22_=_best_of_both_worlds?.html
Bottom line conclusions
- mdraid isn't designed for this, and may not be as resilient as you'd expect
- there is extra overhead involved in the resulting filesystem on
the member, that in this case doesn't actually help fault-tolerance,
makes it more difficult to recover your data from the offsite drive,
and wastes time
- better to just mount a plain-partitioned disk and rsync for your
removable offsite backups
In my case, some of the target filesystems (backup targets with
millions of hardlinks, created by tools like rdiff-backup and
BackupPC) can't be duplicated at the file-level; I need to copy the
filesystem using block-level tools, so that's why the end of the
thread talks about COTS cloning tools as well as FOSS enhanced
versions of dd.
For regular filesystems, IMO rsync's the way to go.
--
To unsubscribe from this list: send the line "unsubscribe linux-raid" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
