that's right, i think the point is... with hardware raid, to 'make a backup' you just need to put disk on array, wait the led to flash red, and get green after sync, and remove the disk... i think he is trying to make this with md (software raid) since we are not hardware raid, software is very better we can make many more commands and know what's in each disk, i think rsync is better, maybe a online backup with md is good, but i don't know if it's really good better than a rsync, or a snapshot at filesystem level (not md problem) just to help with ideas =] 2011/2/8 NeilBrown <neilb@xxxxxxx>: > 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 > -- Roberto Spadim Spadim Technology / SPAEmpresarial -- 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
