Note: "permalinks" may not be as permanent as we would like,
direct links of old sources may well be a few messages off.
On Wednesday 27 October 2010 22:36:06 Lewis Donzis wrote: > The idea was not to use the snapshot as "the backup" but merely to use the > snapshot on the secondary system as a source for other backups. The idea > was to use asynchronous replication so the performance hit during the > backups won't affect the primary. I see, though while using protocol C there still would be a performance hit on the primary node (though depending on your RAID config maybe minimal). But I see no way to backup a secondary DRBD node. > So to answer your question, for individual files, we would be restoring > from some other volume (that has nothing to do with DRBD) back to the > primary via NFS or something like that, and for restoring a whole system, > we'd just use the normal/native DRBD methods on the entire device. > > > Why not make it way easier on yourself and > > configure nested LVM > > on DRBD? You take snapshot on the primary node et voila. > > We have neither available space nor the ability to tolerate the > performance hit of snapshots on the primary. Our eventual goal is to put > SSDs in the primary, at which point we may revisit that idea. I'm not very familiar with primary/primary setups but I guess that such a thing with a clustering file system might provide you with a possibility to read from the second node (on a file level) while the first one is running a resource using the files. But I guess this is what you already have and are looking to dd the complete DRBD device. Do you think you actually still need that while having two copies of the data + third copy of the files themselves?