duplicity-talk
[Top][All Lists]
Advanced

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

Re: [Duplicity-talk] Differential/incremental backups


From: Colin Ryan
Subject: Re: [Duplicity-talk] Differential/incremental backups
Date: Wed, 27 Aug 2008 12:20:43 -0400
User-agent: Thunderbird 2.0.0.16 (Windows/20080708)

Rik,

I'll admit I've not run this fully yet only mocked up the scenario but I've been thinking of the same approach.

I sync to a backup folder from LAN to NAS target folder.
I run rsnapshot on the NAS target folder.
I then run duplicity on the daily.0 rsnapshot folder.

It seems to work as you seem to be hoping, and in my quick experiments the lack of handling of hard links by duplicity is actually beneficial here.

Rsnapshot runs and detects changed _files_ (verses blocks) and does it's rotations. The rotation directories will have the actual changed files in them and are filled in with hard links.

My quick experiments showed that running duplicity in incremental - ( and my understanding it is the type of incremental we want which is changes since the last backup not the last full backup ) - mode against the daily.0 the filled in files since they are inode references are not detected as changed (despite the rsnapshot rotation) , truly new files are detected and the only other thing that is noticed by duplicity is the timestamp on the daily.0 directory itself.

When I ran quickly through this rotations via rsnapshot where there was no changed files and this caused duplicity to ONLY detect the change to the directory timestamp and a modest 1-2 kb destination charge. Likewise when I new there truly was a changed file it would appropriately note this singular file change only and hence would only back up that single file.

So unless I've missed something obvious - i.e. what duplicities incrementals are - it seems to work like you would prefer so I'm curious about your statement of "

I end up with multiple "snapshots" on the offsite
server, as well. Which uses unnecessary disk space (I already have
snapshots locally).

"

Sorry it's not an answer but more a "me too" response.


Rik v. A wrote:
Hi, I've been using Duplicity for a few months now, to create weekly
backups from a backup NAS to an offsite backupserver. Machines in my
network push their backups daily and weekly to a local NAS machine.

Since storage space on an offsite server is expensive, storage
capacity is obviously limited. That's why backups snapshots are
created on the local NAS machine (using rsnapshot), because there's
plenty of diskspace on that machine. That way, as long as my apartment
doesn't burn down, I can always quickly recover a backup from a few
days or weeks ago.

This NAS copies the latest (daily) backup to the offsite backupserver,
every weekend, using Duplicity. However, since Duplicity create
incremental backups, I end up with multiple "snapshots" on the offsite
server, as well. Which uses unnecessary disk space (I already have
snapshots locally).

I could solve this by creating a full backup regularly, however this
defies the whole use of Duplicity; because our upload speed is very
limited, and traffic is expensive, we are forced to use
incremental/differential backups.

What I _really_ want, is a full backup created once, and every time I
run duplicity, it should update this backup, by only updating changed
files.

Kinda like "rsync --verbose --backup --archive --compress --force
--ignore-errors --delete" (which is the line I use to create
incremental backups from one server to the backup NAS), but with the
encryption.

According to Wikipedia
(http://en.wikipedia.org/wiki/Incremental_backup), this is not
incremental nor differential, so I wouldn't know what to call it.

So after this long story, my question is: Is this possible with
Duplicity, and if yes, how?

Kind regards,
Rik v. A


_______________________________________________
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]