Re: [Duplicity-talk] Re: Testing duplicity 0.2.0

[Ben Escoto]

>>>>> "PE" == Peter Ehrenberg <address@hidden>
>>>>> wrote the following on 15 Nov 2002 12:01:40 +0100

  >> Are /d05, /d06, etc. on other filesystems?  [...]
  PE> Unfortunately they are.
  >> Maybe the proposed --exclude-different-device-from would fix your
  >> problem.  [...]
  PE> What speaks against my suggestion to allow more than one source
  PE> directory?

In theory it would probably be fine, but the assumption that there is
a single source directory is made several times.  For instance,
duplicity uses the delta and signature format accepted by rdiffdir,
and that also assumes there is one root dir.  Even the tar format
itself in effect assumes there is one root dir.

    Right now, duplicity keeps track of which host and directory you
are backing up, and warns you if you try to back up a different host.
I think if duplicity were really to support multiple directories it
should do things like:

1.  Allow you to back up different systems to the same directory.
2.  Warn you if it seems you are erasing one system's data with
    another.
3.  Keep track of statistics on a per system level, so you know how
    much space is consumed by each system/directory.
4.  Know which times files were backed up on each directory (don't
    just assume that all files get backed up every session).

Why is it inconvenient just to run 4 separate duplicity instances,
once for each of /d05, /d06, /d07, /d08?  Or if you had an
--include-filesystem switch, would that be as convenient:

--include-filesystem /d05 --include-filesystem /d06 ... --exclude '**'

  PE> OK. Than I have to tell duplicity the period of backup I will to
  PE> keep, right? Assume I run daily backups. Every month I run a
  PE> full dump on the 1st and incrementals on the following days
  PE> until next month. I will keep 4 weeks back up. So every
  PE> "incremental day" I have to delete an (more than 4 weeks) old
  PE> incremental but hold both full dumps --- the last and the last
  PE> before. On the 1st I have to delete the last before full dump.

  PE> Is this to complicated? What may by a useful but simpler backup
  PE> scheme? What schedule do you use?

I haven't run out of disk space yet (hence the missing features :-))
but see below..

  PE> A better scheme may be: "Hold at least given period of time back
  PE> up but leave as much backup as possible and don't use more than
  PE> given disk space."

  PE> Both, the maximal disk space to use and the minimal backup
  PE> period can given duplicity on the command line. If duplicity
  PE> can't meet both constraints it ends up with an error -- or we
  PE> can priorize the constraints, so duplicity is allowed to violate
  PE> either the disk space or the backup period constraint.

This sounds like a useful feature.  But it is several steps away I
think.  Part of the reason I wanted to change the way restores are
done is because I wanted to add a feature where previous full backups
can get integrated with incremental backups.  So I suppose here is
your system (F for full, I for incremental, only 4 day cycle shown,
not monthly, the letters between the ----s represent what backup sets
are available at a given time, and everything is in chronological
order):

----
F
----
F
I
----
F
I
I
----
F
I
I
I
----
F
I
I

F
----
F
I

F
I
----
F

F
I
I
----
F
I
I
I
----

and the cycle continues.  Is this right?  The problem with something
like that is that you may just want to keep the last 4 days at all
times, and with this system sometimes you don't have what came two
days ago.  Also you may not have enough disk space to store two full
backups.  In my case personally, with what I back up, a full backup is
about 1.2 gigs, but a daily increment is 7MB.  So I can store 100
increments but not 2 full sets.

    So a feature I would like to add is to have duplicity combine the
full backup with the oldest increments.  If you ran that process daily
your repository could always have the structure <full backup set> +
<30 incremental sets>.


-- 
Ben Escoto

pgpHH2BP9dGTI.pgp
Description: PGP signature