[linux-lvm] LVM Snapshots for remote archiving.
cbeck at gene.concordia.ca
Wed Jan 28 11:44:02 UTC 2004
I guess I am misunderstanding how a snapshot volume works, I kinda
thought it would be this mythical transaction log - disk writes need to
be stored somewhere while the original volume is frozen and I was hoping
that I could move the whole thing around like any other file.
I was hoping to avoid rsync/rdiff because the snapshot volume itself was
a list of differences over the last 24 hours.
It is whispered that Greg Freemyer was heard, on or about 1/27/2004 6:29
PM to say:
>On Tue, 2004-01-27 at 18:03, Chris Beck wrote:
>>Hi! I've been looking through the archives and I can't see anything
>>addressing my issue. Probably because I didn't look hard enough.
>>I want to use 24-hour snap shots as an archival tool.
>>I have 2 identical file servers, one primary and one as an off-site
>>mirror. I'd like the primary system to generate a transaction log that
>>rolls over every 24-hours and gets transmitted to the remote site.
>>After 7 days on the remote site, the log gets triggered so the remote is
>>always 7 days out of sync but with the last 6 days logs ready to go. I
>>could have it auto update on arrival, but I was thinking that allowing a
>>week for someone to realize that they deleted something vital would be a
>>good thing(TM) - standard archiving stuff I guess.
>>Do you think that lvm snapshot volumes are a simple and convenient way
>>of doing this? Does this make sense at all?
>The above transaction log is new to me. I have seen that done with
>databases, but not with generic fileservers.
>If I was trying to accomplish what I think are your goals, I would use
>I don't know the syntax offhand, but the process would be:
>mount snapshot as /snap
>rdiff-backup /snap //backup_server/snap
>rdiff-backup --delete_older_than 7-days //backup_server
>rdiff-backup uses technology similar to rsync to ensure only the deltas
>are sent between the servers. (ie. first check datestamps etc. to see
>if file changed. If so, use md5sums to isolate what parts of the file
>changed and send them between the servers.)
>It maintains a current copy of the source files, and a series of diffs
>to go backwards to older versions of the files. In the above it would
>keep a max of 7 diffs per file. If you wanted to restore from 7 days
>prior, rdiff-backup would internally have to apply all 7 diffs, one
>rdiff-backup has lots of other features/capabilities.
>Also, it uses ssh to encrypt all data between the servers, so it is also
>The only problems I have with rdiff-backup are:
>1) ACL and EA support is only in the Unstable release, but they seem to
>be working fine
>2) rdiff-backup is written in python and when an unhandled error occurs,
>it dumps out a stack trace. To see what the problem is you have to go
>thru the stack trace and the code. Not to bad if you have some
>programming skills. If not, the mailing list is fairly responsive.
>There is a wiki at
Chris Beck / Y.A.B.A. / Fungal Genomics
CFSG / Concordia University
"La loi dans sa majestueuse égalité, interdit à tous, aux riches comme
aux pauvres de dormir sous les ponts, de coucher dans la rue et de voler
du pain." -- Anatole France (Les Lys Rouge - 1894)
More information about the linux-lvm