[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Duplicity-talk] Direct backup of LVM snapshot partitions?
From: |
edgar . soldin |
Subject: |
Re: [Duplicity-talk] Direct backup of LVM snapshot partitions? |
Date: |
Mon, 10 Dec 2012 13:20:53 +0100 |
User-agent: |
Mozilla/5.0 (Windows NT 5.1; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 |
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
>
- [Duplicity-talk] Direct backup of LVM snapshot partitions?, George MacKerron, 2012/12/07
- Re: [Duplicity-talk] Direct backup of LVM snapshot partitions?, George MacKerron, 2012/12/10
- Re: [Duplicity-talk] Direct backup of LVM snapshot partitions?, edgar . soldin, 2012/12/10
- Re: [Duplicity-talk] Direct backup of LVM snapshot partitions?, George MacKerron, 2012/12/10
- Re: [Duplicity-talk] Direct backup of LVM snapshot partitions?,
edgar . soldin <=
- Re: [Duplicity-talk] Direct backup of LVM snapshot partitions?, GDR!, 2012/12/10
- Re: [Duplicity-talk] Direct backup of LVM snapshot partitions?, edgar . soldin, 2012/12/10
- Re: [Duplicity-talk] Direct backup of LVM snapshot partitions?, GDR!, 2012/12/11
- Re: [Duplicity-talk] Direct backup of LVM snapshot partitions?, edgar . soldin, 2012/12/11
- Re: [Duplicity-talk] Direct backup of LVM snapshot partitions?, T. Prost, 2012/12/11
- Re: [Duplicity-talk] Direct backup of LVM snapshot partitions?, edgar . soldin, 2012/12/11
- Re: [Duplicity-talk] Direct backup of LVM snapshot partitions?, T. Prost, 2012/12/12
- Re: [Duplicity-talk] Direct backup of LVM snapshot partitions?, edgar . soldin, 2012/12/12
- Re: [Duplicity-talk] Direct backup of LVM snapshot partitions?, T. Prost, 2012/12/12
- Re: [Duplicity-talk] Direct backup of LVM snapshot partitions?, edgar . soldin, 2012/12/12