duplicity-talk
[Top][All Lists]
Advanced

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

Re: [Duplicity-talk] [newbie] backup nesting filetrees?


From: David Rea
Subject: Re: [Duplicity-talk] [newbie] backup nesting filetrees?
Date: Thu, 13 May 2010 00:46:45 -0400

Hi Tom-

It sounds like you're trying to do more work than Duplicity requires. If I'm reading this right, you want to have a single backup destination containing both your infrequent and frequent targets.

The simplest way to do this with Duplicity would seem to be to have a single backup job covering your entire home directory, running at your higher desired frequency (daily). Since Duplicity's normal run mode is incremental, this will cover your frequently-updated targets while not needlessly duplicating your infrequently-updated targets.

The key will be performing a periodic full backup at your lower desired frequency (weekly). This will produce additional (or call them supplemental) full backups on your backup destination, providing some redundancy. So far, that's what you've already described in your OP.

The only thing I'd add is a weekly pruning step along with (err, immediately following) the weekly backup. You can use "remove-older-than" in a forced duplicity run to do this by date, or "remove-all-but-n-full" to do it by count.

Cheers,
Dave

On Wed, May 12, 2010 at 10:58 PM, Tom Roche <address@hidden> wrote:

I'm wondering how duplicity can accomplish the following usecase.
(Please excuse any failures of understanding or vocabulary.)

Because I update some files more frequently than others, my home
(call it "/home/me") has

* a large number of subtrees which change relatively slowly (e.g.
 /home/me/refs)

* a small number of subtrees which change relatively quickly (notably
 /home/me/logs).

I thus prefer to backup /home/me/logs more frequently (e.g. daily) and
/home/me/refs less frequently (e.g. weekly). However as noted there are
many more slow-changing subtrees than fast-changing ones; while it is
easy to explicitly backup the fast-changers, it is more tedious to
explicitly backup the slow-changers. With my current backup "tool"
(simple scripts driving raw `rsync`) I accomplish this by backing up,
incrementally, to the same media,

* daily:  /home/me/logs -> /backup/home/me/logs
* weekly: /home/me      -> /backup/home/me

(At longer intervals I pull media out of the backup pool and stash them
away.) Thus I get frequent explicit backups of the fast-changers, and
less frequent, implicit backups of the slow-changers (which constitute
the rest of the whole home space in which they nest). This works because
each backup is a simple mirror of its source, so backups can nest within
each other just as filetrees do. I can also backup any particular
subtree when I know something important has changed within it.

However `duplicity` is tar-ing and compressing, not just mirroring, so
I'm suspecting the above strategy just won't work. I.e. I can't have
one `duplicity` backup nested within another. Is that correct?
If so, I'm suspecting the most, umm, "duplicitous" way to capture
regular changes in a subspace is just to backup the whole space, e.g.

* daily:  incremental backup of /home/me
* weekly: full backup of /home/me

Is that correct?

Apologies if this is a FAQ, but a brief search (which may have used
quite the wrong search terms) found nothing related.

TIA, Tom Roche <address@hidden>

_______________________________________________
Duplicity-talk mailing list
address@hidden
http://lists.nongnu.org/mailman/listinfo/duplicity-talk


reply via email to

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