duplicity-talk
[Top][All Lists]
Advanced

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

Re: [Duplicity-talk] Direct backup of LVM snapshot partitions?


From: George MacKerron
Subject: Re: [Duplicity-talk] Direct backup of LVM snapshot partitions?
Date: Mon, 10 Dec 2012 12:16:09 +0000

Thanks Edgar. Yes, I'm already using LVM snapshots. I just wanted to then back 
up the raw volume data, rather than mount the snapshot and back up the files it 
contains.


On 10 Dec 2012, at 12:13, address@hidden wrote:

> On 10.12.2012 12:58, George MacKerron wrote:
>> Thanks Martin, that's really helpful -- I'll investigate rdiff.
>> 
>> I guess an alternative feature that would support this use case might be 
>> duplicity backup of data from stdin (possibly with a nominal file name)? 
>> Then I could do something like:
>> 
>> dd if=/dev/blah | duplicity --stdin-data=devblah.img ...
>> 
>> In fact, the main thing I normally use duplicity for is backup of Postgres 
>> pg_dump output, and it seems like this would be really useful there too 
>> (avoiding a lot of disk space wasted on temporary files, and a lot of 
>> thrashing the disk) -- i.e.
>> 
>> pg_dump … | duplicity --stdin-data=mydb.sql ...
>> 
>> But perhaps there are reasons this wouldn't work -- such as needing random 
>> access to the data being backed up?
>> 
> 
> duplicity reads the data blockwise as a stream. so theoretically you could 
> extend duplicity to do a one "file" backup from STDIN . but that is some 
> major work, as _all_ of duplicity's actions would have to be modified and you 
> will have to work around the file attributes, which probably are not valid or 
> existing for the stream.
> 
> having said that. the easiest would be probably shell scripting a solution 
> that pipes eventually into gpg, if you really insist on having no physical 
> file anywhere.
> 
> using snapshots seems the easiest way to go for your scenario to me though. 
> you still haven't given a rationale not to use them. you risk backing up 
> corrupted data if you simply dump the device, you realize that right?
> 
> ede/duply.net

Attachment: smime.p7s
Description: S/MIME cryptographic signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]