On Tue, 8 Feb 2011 03:37:40 -0200 Roberto Spadim <roberto@xxxxxxxxxxxxx> wrote: > i think that a 4 disks array using spare disks is better If all you are saying is that 4 disks are better than 3 disks - then yes: obviously. If you want to rotate two of them out independently it would still be best to have 2 stacked RAID1 arrays as then the resync time will be lots shorter. Or where you saying something else? NeilBrown > first... if you remove 1 mirror (2 mirrors maybe 2 disks...), you have > a protection problem (you don't have redundat array with only 1 mirror > working) > with 4 disks... 2 mirrors, to start backup put a spare online, wait it > to sync, remove it > if you have problem when resync, you have a second spare (the new > backup), and consider the resync disk, as the new array disk (not more > a backup disk) > > it's like a online backup... i think we can implement it as snapshot > (on filesystem level) but since we can make it at lower level, it's a > nice feature... i think 4 disks is more secure... 3 disks is just more > cheap.. > > 2011/2/8 Leslie Rhorer <lrhorer@xxxxxxxxxxx>: > > > > > >> -----Original Message----- > >> From: linux-raid-owner@xxxxxxxxxxxxxxx [mailto:linux-raid- > >> owner@xxxxxxxxxxxxxxx] On Behalf Of NeilBrown > >> Sent: Monday, February 07, 2011 6:18 PM > >> To: Jeff Klingner > >> Cc: linux-raid@xxxxxxxxxxxxxxx > >> Subject: Re: raid1 with rotating offsite disks for backup > >> > >> On Mon, 7 Feb 2011 15:53:46 -0800 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. > >> > > >> > My questions are: > >> > > >> > In step 3b, when a disk that was a member of the array in the past but > >> has been removed for a while is re-inserted into the 3-disk array, how > >> does the raid system know to update C with A's contents and not A with C's > >> contents? Is there a timestamp involved, and if so, how can I examine it > >> before syncing? > >> > > >> > Is it important to always rotate disks B and C, leaving one that never > >> leaves the computer, or does it make no difference which of the two live > >> disks I pluck out to swap with the offsite disk when I make the trip? Can > >> all three disks take turns offsite, so that they all have the same duty > >> cycle? > >> > > >> > I saw in another list message the advice to use two stacked raid1s for > >> this application: http://marc.info/?l=linux-raid&m=126761399008775&w=2 > >> > > Also, if you want two rotating backups I would create two stacked > >> raid1s. > >> > > > >> > > mdadm -C /dev/md0 -l1 -n2 -b internal /dev/main-device /dev/first- > >> backup > >> > > mdadm -C /dev/md1 -l1 -n2 -b internal /dev/md0 /dev/second-backup > >> > > mkfs -j /dev/md1 > >> > > >> > > >> > Are there important differences between the single 3-disk raid1 array > >> I'm planning to use and this stacked configuration? > >> > >> Yes. The single 3-disk RAID1 array won't work, the stacked configuration > >> will. > > > > Oh. I think I mis-read his original post. When I read it the first > > time, I inferred he was attempting this to do a full backup of the array. > > Reading again, I think you are correct. If he wants to just update the data > > on the array, I think rsync (or maybe dar) would be a better solution. If > > he wants a full backup from scratch, I don't see why a RAID1 solution would > > not work, do you? > > > >> md can resync 'just the changed blocks' by using the 'write intent bitmap' > >> and event counters. > >> However it only clears the bits in the bitmap when the array is not > >> degraded. > >> In your suggestion the 3-drive RAID1 is always degraded so bits are never > >> cleared, so each resync is effectively a complete resync. > > > > Yeah, to do a full backup from scratch, I think I would set the > > array up as a 2 drive array, take the array off-line, remove one drive, > > assemble the array, and then add the spare. 'Clumsy, though. I still think > > he would be better off with rsync or dar. > > > > -- > > 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 > > > > > -- 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
