[Top][All Lists]

[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.


reply via email to

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