From mboxrd@z Thu Jan 1 00:00:00 1970 From: NeilBrown Subject: Re: raid1 with rotating offsite disks for backup Date: Tue, 8 Feb 2011 17:07:45 +1100 Message-ID: <20110208170745.0d79f849@notabene.brown> References: <20110208111743.1479308d@notabene.brown> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: QUOTED-PRINTABLE Return-path: In-Reply-To: Sender: linux-raid-owner@vger.kernel.org To: Roberto Spadim Cc: lrhorer@satx.rr.com, Jeff Klingner , linux-raid@vger.kernel.org List-Id: linux-raid.ids On Tue, 8 Feb 2011 03:37:40 -0200 Roberto Spadim 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 ye= s: obviously. If you want to rotate two of them out independently it would still be b= est to have 2 stacked RAID1 arrays as then the resync time will be lots short= er. Or where you saying something else? NeilBrown > first... if you remove 1 mirror (2 mirrors maybe 2 disks...), you hav= e > a protection problem (you don't have redundat array with only 1 mirro= r > working) > with 4 disks... 2 mirrors, to start backup put a spare online, wait i= t > 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 mor= e > a backup disk) >=20 > 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 mor= e > cheap.. >=20 > 2011/2/8 Leslie Rhorer : > > > > > >> -----Original Message----- > >> From: linux-raid-owner@vger.kernel.org [mailto:linux-raid- > >> owner@vger.kernel.org] On Behalf Of NeilBrown > >> Sent: Monday, February 07, 2011 6:18 PM > >> To: Jeff Klingner > >> Cc: linux-raid@vger.kernel.org > >> Subject: Re: raid1 with rotating offsite disks for backup > >> > >> On Mon, 7 Feb 2011 15:53:46 -0800 Jeff Klingner > >> wrote: > >> > >> > I'm planning a backup system for my home server and have run int= o 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 (cal= l the > >> disks A, B, and C). > >> > 2. Remove disk C, put it offsite. =A0("offsite" is moderately ti= me- > >> consuming to get to.) > >> > 3a. Periodically, remove disk B, take it offsite, and retrieve d= isk C > >> > 3b. Insert disk C, which will be re-synced to gain any changes m= ade > >> 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 dele= ted > >> data. > >> > > >> > My questions are: > >> > > >> > In step 3b, when a disk that was a member of the array in the pa= st 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? =A0Is there a timestamp involved, and if so, how can I e= xamine 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 tw= o live > >> disks I pluck out to swap with the offsite disk when I make the tr= ip? =A0Can > >> 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 raid= 1s for > >> this application: http://marc.info/?l=3Dlinux-raid&m=3D12676139900= 8775&w=3D2 > >> > > Also, if you want two rotating backups I would create two stac= ked > >> raid1s. > >> > > > >> > > mdadm -C /dev/md0 -l1 -n2 -b internal =A0/dev/main-device /dev= /first- > >> backup > >> > > mdadm -C /dev/md1 -l1 -n2 -b internal /dev/md0 /dev/second-bac= kup > >> > > 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. =A0The single 3-disk RAID1 array won't work, the stacked conf= iguration > >> will. > > > > =A0 =A0 =A0 =A0Oh. =A0I think I mis-read his original post. =A0When= 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. =A0If he wants to just upda= te the data > > on the array, I think rsync (or maybe dar) would be a better soluti= on. =A0If > > he wants a full backup from scratch, I don't see why a RAID1 soluti= on 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 no= t > >> degraded. > >> In your suggestion the 3-drive RAID1 is always degraded so bits ar= e never > >> cleared, so each resync is effectively a complete resync. > > > > =A0 =A0 =A0 =A0Yeah, to do a full backup from scratch, I think I wo= uld set the > > array up as a 2 drive array, take the array off-line, remove one dr= ive, > > assemble the array, and then add the spare. =A0'Clumsy, though. =A0= I still think > > he would be better off with rsync or dar. > > > > -- > > To unsubscribe from this list: send the line "unsubscribe linux-rai= d" in > > the body of a message to majordomo@vger.kernel.org > > More majordomo info at =A0http://vger.kernel.org/majordomo-info.htm= l > > >=20 >=20 >=20 -- To unsubscribe from this list: send the line "unsubscribe linux-raid" i= n the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html