[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