Re: raid1 with rotating offsite disks for backup

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



i agree with rsync
rsync is more filesystem related feature
if you want copy files, you should use rsync
if you want to copy the device, may be a dd with devices?
dd if=/dev/md0 of=/dev/sda

if you want a snapshot copy, you should first remount your filesystem
to readonly (there´s no flock() for /dev/md0 since filesystem don´t
use flock() on /dev/md0) or another way to block writes to filesystem
while you is read from device, some filesystems have online backup
features..
i don´t know lvm very well, but maybe they implement online backup there...
i don´t think it´s a problem to solve at md level (it could work, but
the raid1 purpose is make a fail safe device (or partially safe), not
a online backup device)


2011/2/9  <hansbkk@xxxxxxxxx>:
> 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
>



-- 
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


[Index of Archives]     [Linux RAID Wiki]     [ATA RAID]     [Linux SCSI Target Infrastructure]     [Linux Block]     [Linux IDE]     [Linux SCSI]     [Linux Hams]     [Device Mapper]     [Device Mapper Cryptographics]     [Kernel]     [Linux Admin]     [Linux Net]     [GFS]     [RPM]     [git]     [Yosemite Forum]


  Powered by Linux