[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Duplicity-talk] Incremental Backups always against the last full sn
From: |
Dmitry Chernyak |
Subject: |
Re: [Duplicity-talk] Incremental Backups always against the last full snapshot |
Date: |
Sun, 18 Dec 2011 03:33:42 +0400 |
User-agent: |
Roundcube Webmail/0.5.3 |
Hello, Daniel!
On Sat, 17 Dec 2011 15:14:47 +0100, Daniel Weigl wrote:
Is there a technical reason which might block this idea?
duplicity currently assumes that incrementals are based on the
backup
set before the incremental, hence these "full-incrementals" would
have
to be tagged for duplicity to detect that they are based on the full
set.
I see two options:
a) Maybe call them "diff" (as Eliot Moss suggested)
b) Leave the filename as it is, just relay on the option given to
duplicity (so the user must pass it for all action - backuping,
restore...
just like "--no-encryption")
Please note, that the current incrementals naming scheme is the chain.
Each incremental backup have the "parent" stamp and the "current"
stamp.
The "parent" stamp belongs to the previous incremental or full backup.
It is good (just hard for parsing :)
In the case of the differential backup we just need to make the new
incremental backup against the last full.
No collisions will be here - we'll got the branch: there will be two
incrementals with identical parent stamp and with separate "current"
stamp. The next incremental will be based on the latest "current".
Currently I using the hand-made script, which moves all incrementals to
the separate folder (named with date).
That folder also have the symlinked copies of the last full backup.
(The actual scheme is a bit complex, I can decribe it if there will be
the interest).
As the result, the next incremental backup will be actually
differential.
To restore from the past weeks incremental you'll need to point
duplicity to the right subfolder of the current backup target.
The advantage of this scheme is that the backup folder will not be
saturated with many backup files over the time.
---
WBR, Dmitry.