duplicity-talk
[Top][All Lists]
Advanced

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

Re: [Duplicity-talk] Show volume Duplicity is working on


From: edgar . soldin
Subject: Re: [Duplicity-talk] Show volume Duplicity is working on
Date: Sat, 18 Oct 2014 15:26:10 +0200
User-agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0

On 18.10.2014 15:13, Remy van Elst wrote:
> 
> 
> On 10/18/14 14:49, address@hidden wrote:
>> 1. exactly what are you trying to achieve? 
> 
> I have a server with 1.6 TB of data that takes almost a week to do a
> full backup over an umetered gbit connection. It backs up to Rackspace
> Openstack Swift, with a default 25MB volume size.
> 
> The backup becomes inconsistent because stuff changes a lot on that
> server. It has multiple +100 GB databases running. I sent an email
> earlier to this list regarding --max-blocksize, but did not receive a
> response yet.

you are doing snapshots or dumps of those right?

> (http://lists.nongnu.org/archive/html/duplicity-talk/2014-10/msg00002.html)
> 
> With a volume size of 250 MB, or with 2048 MB the upload still takes
> more than 3 days sadly.
> 
> What I want to achieve is solving the long running backup issue.

do the backup to a local file:// target. that'd should be fast, at least as 
fast as possible. then sync this with a swift client to your backend.
 
>> 2. why do you need to know which volume is uploaded?
> 
> I was troubleshooting with strace and saw the volume number. I know the
> volume size, so with the current volume number I know which one is being
> uploaded (async upload enabled). With that data I should be able to
> estimate how far the backup is.

for that you can enable verbose logging or progress meter, although the latter 
is sometimes not working properly.
 
>> 3. duplicity is written in python script language. you can easily patch your 
>> local duplicity to print out the current volume name.
>>
> 
> Is also an option, however I would use that as a last resort. I'm using
> Duplicity 0.6.24, compiled from source on Debian 7.

try the solution, separate upload, above. that way the backup will not have to 
wait for the upload top finish.

..ede/duply.net



reply via email to

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