Commandline syntax (WAS: RE: Restore behavior for 'current_mirror .*.snapshot ?' )

[Jason Piterak]

Ben,

> -----Original Message-----
> From: ben@stanford.edu [mailto:ben@stanford.edu]On Behalf Of 
> Ben Escoto
> Sent: Monday, April 29, 2002 1:30 AM
> To: Jason Piterak; rdiff-backup@keywest.Stanford.EDU
> Subject: Re: Restore behavior for 'current_mirror.*.snapshot ?' 
> 
> 
> >>>>> "JP" == Jason Piterak <Jason>
> >>>>> wrote the following on Wed, 24 Apr 2002 11:17:18 -0400
> 
>   JP> The problem I'm running into is that the current restore command
>   JP> is good for admins or even power users, but most users just want
>   JP> to be able to say: "I want a restore of these files or
>   JP> directories as of this date ("2002-04-24T10:51:55-0400" or "-1
>   JP> day" or "-1 week"), and I want it in this directory." 
> 
> Yes, I think you are right.  Perhaps then rdiff-backup needs a new
> restoring syntax, for instance:
> 
> rdiff-backup -r 1D /backup/usr/local/foo /tmp/output
> rdiff-backup -r "2002-04-24T10:51:55-0400" 
> /backup/usr/local/foo /tmp/output
> 
> which would mean something like "Put the contents of
> /backup/usr/local/foo as they were 1 day ago (or, in the second case,
> as they were on April 24th, 10:52am) and put them in /tmp/output".
> 
>     I'm not sure if this is very intuitive, but right now I can't
> think of a better syntax.  It would also solve the problem of how to
> specify restoring the current state; something like:
> 
> rdiff-backup -r now /backup/usr/local/foo /tmp/output
> 
> (or instead of "now" any time after which no changes were recorded)
> could be used to restore an arbitrary directory as it currently is.

 That would be perfect.
  Giving a time period:
   rdiff-backup -r 1M2W4D2H5m20S /backup/usr/local/foo /tmp/output
   ...would give you a restore relative to now: (1 month, 2 weeks 4 days 2
hours 5 minutes and 20 seconds ago ... phew). 
   Giving the iso-8601 date gives restore as of an absolute date. 
  (BTW, the GNU 'date' command in bash is horribly buggy, esp with regards
to timezones and iso datestamps. I just mention this for the next poor soul
who tries to do future scripting of rdiff-backup in bash -- they might want
to steer clear of it... ).
   The result of a restore of 'now' or of a date after the current backup is
intuitive, and exactly what I would expect.

    The only thing that would be tricky with this syntax is dealing with a
directory/file that has been moved or deleted... There has to be a way to
say "give me all iterations of the file/directory matching this <regex/shell
glob/string, etc.>" Would it make sense that this match the backup:
   rdiff-backup --include[-filelist|filelist-stdin|regexp...]
/backup/usr/local/foo /tmp/output

... Something like:
rdiff-backup -l --include[-filelist|-filelist-stdin|-regexp...]
/backup/usr/local/foo

  There may even be some use for --include-* or --exclude-* command line
parameters in the context of a restore...
  rdiff-backup -r 1M2W4D2H5m20S --include very_important_file-* /home/foo
/tmp/output

  = "restore any file starting with 'very_important_file-' from the foo's
home directory as they were 1 month 2 weeks... ago"


   I think you're right, as far as the increments list being a higher
priority for a scripted interface. At least if you can get the list of
increments to the user first, you can have them choose the file to restore.
This would cut down on the need for --include or exclude from restores
(though I personally would find this rather useful...)

   BTW: Would it make sense to start thinking of the commandline syntax as
being in different 'contexts'. (like cvs or rpm) ie: you would have the
context of a backup, with no commandline switch (or -b ):
   rdiff-backup --include|exclude[-filelist|filelist-stdin|regexp...]
/backup/usr/local/foo /tmp/output

  Then you would have the context of an iteration list, with the '-l'
switch:
   rdiff-backup -l
--include|exclude[-filelist|filelist-stdin|regexp...]<expression>
/backup/usr/local/foo

  And the context of a restore, with the '-r' switch:
   rdiff-backup
--include|exclude[-filelist|filelist-stdin|regexp...]<expression>
/backup/usr/local/foo /tmp/output

  ... Other commandline switches, like --no-compression might fit into one
or more contexts, but not others.


> 
>   JP>   s'ok... I'll just change my program logic so that it says: o
>   JP> Look in the corresponding rdiff-backup-data directory:
> 
>   JP> - If the request is for a dir, look at the *.dir or *.missing
>   JP> files in the dir above requested restore dir.
>   JP> - If the request is for a file, look at the *.missing or
>   JP> *.snapshot files in the corresponding filepath.
> 
> Well, what if a file went from being a regular file to a directory or
> vice-versa?  Why not just choose the oldest increment file newer than
> the specified time with the correct prefix (i.e. prefix equals
> filename of file you want to restore)?

  Hmmm, good thought. I would assume that the user would want the file/dir
AS IT WAS as of the date requested, so I'll have to look in both locations
for files with the right prefix (though a restore of the entire archive
means restoring from the correct rdiff-backup-data/'increments' file, not
the directory name, right?). 
  As for which increment file to choose... You'd really be looking for the
first file OLDER than the restore date, right?

> 
>   JP>  If there's an rdiff file older and newer than the requested
>   JP> date, then restore using rdiff-backup and the older file.  o If
>   JP> there is no newer rdiff file, then copy the files from the
>   JP> current archive.
> 
> You probably mean "rdiff-backup increment file" instead of "rdiff
> file"?  It think it is right then, but I don't understand the part
> about the file being "older and newer than the requested date".
> 
  Yes, sorry, I should have been more exact with my syntax. 
  As far as the rest of it, to clarify:
  o If item to restore has no increment/dir/snapshot files newer than the
restore date, restore from current archive. (ie: there has been a backup and
change after the restore date, so the data for this date must come from an
increment file...)
  o If item has increment/dir/snapshot files newer than the restore date,
restore from the first rdiff-backup increment file older than the requested
restore date.
  


  Again, thanks for the trouble!

Take care,
--Jason