[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[rdiff-backup-users] feature requests and notes
From: |
Andrew K. Bressen |
Subject: |
[rdiff-backup-users] feature requests and notes |
Date: |
Mon, 27 Oct 2003 03:42:45 -0500 |
User-agent: |
Gnus/5.1002 (Gnus v5.10.2) XEmacs/21.4 (Informed Management, darwin) |
Hi--
I have some feature request/suggestions:
(1) python errors are wonderfully informative compared to most
environments these days, but not so easy to automatically parse.
If rdiff-backup could spit some indicator at the beginning and
end of each error stack, that would make writing log parsers
much easier. I usually run at -v6; I don't know if running at
a lower level would be more easily parseable. I have found this
to be a useful level for diagnostics/bug reporting.
Actually, it comes to mind that perhaps outputting the log level
of each message at the start of the line would be useful, so I could
grep out the level one or two output to read and keep the lower
level stuff in case it is needed later.
(2) from reading the list, it seems that sometimes (as when a file
in the backup dir is inadvertantly deleted) users may have to
manually dink with the metadata. It'd be cool if there were tools
to do this programmatically, such as options to delete the latest
or all versions of a file from the archive, or to sync the metadata
to the archive contents.
I'm unclear on if --check-destination-dir does anything besides
back out the failed increment attempt.
(3) in re space management by number of backup cycles instead of
by dates, Ben said:
"Yes, it's a good idea. How about if a new time specification was
allowed, so that '--remove-older-than 4B' would remove everything
older than the 4th Backup session? It could be useful when restoring
also, e.g. '--restore-as-of 2B'."
I thought of a new failure scenario that might complicate this syntax.
If my daily backup scripts do a --remove-older-than 7D and something
goes wrong with backing up, but not the remove, for 8 days, I could be
in trouble. Ideally, a way to tell --remove-older-than to retain a
certain minimum number of copies would be a safety, and I don't think
the above syntax quite allows for that. Similarly, if one has been
doing lots of tests and reruns one day, perhaps one would want to make sure
to have several days worth of backups around.
Perhaps a --retain-at-least that also took
<number> smhDWMY and <number> B args?
(4) is the TODO list up somewhere accessible?
(grep grep) here's what I have noted:
requests that have been ack'd as feasible/reasonable:
dry-run option
maybe a full-compare integrity check
requests that may not be practical:
"There is no option to remove just the number of increments that
would let you complete the current backup"
removing an intermediate increment
[s]locate(1) functionality
md5 sums
file integrity (tripwire/integrit) functionality
decent sparse file handling (seems to be nonportable)
retrieve increment history of a specific file
stuff with non-rdiff-backup dependencies:
mac os x does not support python acl calls
(I'm unclear on the real-world impact of this;
do any mac fs' support acls?)
situation on windows and samba time granularity unclear
situation on NFS unclear
(5) Ben, a while back you said that a file mv was handled as a delete and
an add of the whole file. But I noticed in some later mail you talked about
tracking changes via inodes vs. md5 sums. Does this mean that at some
point one or both will be implemented? Does that in turn mean that
mv's could be detected?
(6) Documentation
the man page linked from http://rdiff-backup.stanford.edu/docs.html
doesn't say what version it's for or when it was made.
http://rdiff-backup.stanford.edu/format.html
claims to be current for 0.6, and I know metadata handling
has changed dramatically since then...
--akb
- [rdiff-backup-users] feature requests and notes,
Andrew K. Bressen <=