duplicity-talk
[Top][All Lists]
Advanced

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

Re: [Duplicity-talk] Backing up desktop virtual machines?


From: edgar . soldin
Subject: Re: [Duplicity-talk] Backing up desktop virtual machines?
Date: Mon, 21 Jul 2014 10:51:51 +0200
User-agent: Mozilla/5.0 (Windows NT 5.1; rv:24.0) Gecko/20100101 Thunderbird/24.6.0

On 21.07.2014 07:50, Rubin Abdi wrote:
> Hello.
> 
> So I've been using Duplicity for the last week (wrapped with duply) and
> it's been great. My only current sore spot is if I touch any of my
> virtual machines (through Virtual Box), a backup jumps from 15 minutes
> to over 2 hours. And so I have three questions.

how many GB's are we talking about. what's your OS?
 
> The first one I'm pretty sure the answer is no, is there any way to
> backup only the changes within the vdi volume container file to my
> Duplicity session?

incrementals do exactly that. make sure the virtual machine is paused/stopped 
to prevent file system (fs) corruption.

> 
> Given that the answer to the first question is no, is there any sane way
> of ignoring my virtual machine directory for incremental backups until I
> decided it's time to also include the new changes to the virtual machine
> directory?

in/exclude via globbing file or such.. see manpage

> And so, is there any way to have Duplicity only maintain two versions of
> files in a particular directory while still having that be included in a
> full system backup?

possible, but different backup sets sounds a more natural approach.

however, if done via in/exclude duplicity would mask the source fs accordingly 
and the files would appear as "freshly" created in fulls and deleted in 
following incrementals (because missing in the source fs).
 
> If the answer two question two is either no, or too much of a pain, I'm
> guessing my only solution really is to have a separate Duplicity session
> for the virtual machines that I run once in a while and only maintain
> two revisions.

try to find out the bottleneck in your vm backup first. is it the upload or the 
backup itself (test backup to local file:// target). knowing that you might be 
able to speed up things or in the worst case split backups.


..ede/duply.net



reply via email to

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