Re: [Duplicity-talk] Version 0.6.0 Released - Checkpoint/Restart

[Eric Evans]

[ Kenneth Loafman ]
> The thing I realized before I finished this was that there needed to be
> some way to 'name' a backup set.  Right now, you can use an option like:
> --archive-dir=~/.duplicity/backup_name, but I'd like to move to the
> point where each backup had its own directory, located by name, with all
> the options stored in the directory along with the sig and manifest
> files, but then I took it another step.
> 
> It would be handy to use a database for all of this, both the sig and
> manifest info could be stored in the database, along with options, logs,
> and history.  An SQL database could be used for this quite easily, but
> my issue with database access is that now you're into major program
> requirements that get away from small size.  Plus, to be a true backup,
> you have to store the same info remotely so nothing is lost if the
> backup machine dies, which kind of implies multiple formats.  I don't
> think you'd want to shove a database over the wire for a backup.

Can I ask what caused you to take that extra step (database, as opposed
to files stored in a backup-specific directory)? It seems pretty
straightforward to store all of this to disk.

> Bottom line is that I'm strongly thinking of rewriting or at least doing
> a major re-org on duplicity.  After going through all of this and getting
> a fairly good understanding of duplicity, I think it has out-grown it's
> original purpose and needs to either be pared down and simplified, or
> enhanced and functionally completed into something that will handle
> major backup tasks.

If you decide to go down the latter path, it's probably worth looking at
what you have planned and comparing that to existing backup solutions to
see if you're bringing anything new to the table.

FWIW, I think there is a niche for backup software that falls somewhere 
between using cp/scp/rsync/tar/etc directly, and systems like bacula and
amanda (does anyone still use this?); duplicity fills this niche pretty
nicely IMO.

> Some thoughts come to mind:
> - Named backups, i.e. named directory or keyed database entries.
> - Plugin style backends, i.e. we supply basic backends, others are able
> 
>   to be plugged in by just putting them in a plugin directory.
> - Get away from tar for backend data structure.
> - Allow incrementals to be folded forward into a new complete set.

This would be pretty neat. Is there any reason this couldn't be
implemented as a separate utility right now, something that could be
run independently on a remote backup host?

> - Differential backups, folded incrementals would be necessary for this.
> 
> Sorry, just rambling...

-- 
Eric Evans
address@hidden