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

[edgar . soldin]

that is dangerous.. don't do that (file corruption), either
a. backup a snapshot
b. backup from where the filesystem is mounted

backing up a database dump is another scenario and could be dealt with the 
piping solution described below.

..ede/duply.net

On 10.12.2012 13:16, George MacKerron wrote:
> 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
>