Known hot-backup.py problems [was: hot-backup.py hangs]

Philip Martin <philip@codematters.co.uk> writes:

> Overall hot-backup.py is less than perfect

I don't use hot-backup.py (I backup offline) so I have never really
taken much interest in it before. Having now looked at it, I believe
there are at least 5 problems.

1. db_archive and db_recover (not serious)
The script calls db_archive and db_recover and hardcodes the path to
these utilities. It should be using svnadmin from SVN_BINDIR. This
should be straightforward to fix.

2. 'svnlook youngest' race (not serious)
The name of the backup incorporates a revision number obtained by
running 'svnlook youngest' on the live repository before starting the
backup. However the youngest revision may change during the time
taken to backup and the name could be misleading. One solution would
be to make the backup using a temporary name and rename it when
complete using the revision obtained by running 'svnlook youngest' on
the backup rather than the live repository. Another solution, for use
when hot-backup.py is run from a post commit script, would be to pass
the commit revision and name the backup using that.

3. backup name race (very serious)
As described in my previous mail. The name of the backup is chosen by
getting a directory listing, choosing a name that is different from
all the names in the listing and then copying into that name. Nothing
prevents parallel instances of hot-backup.py choosing the same name so
that the copies overwrite each other, which will lead to missing
and/or corrupt backups. One solution is that the hot-backup.py should
mkdir the chosen name before copying, then only one instance can
succeed and any others will have to try another name (at least that's
what I would do in C, I'm assuming Python works the same).

4. log file removal race (serious)
After making a backup hot-backup.py deletes those log files that are
no longer in use from the live repository. However these log files
may have been in use when the backup was made. That means that some
log files might never be complete in any of the backups, in an extreme
case some log files may not appear in any backup at all. If the
complete version of a log file is missing it means that catastrophic
BDB recovery will not be possible. One solution would be to get the
list of complete log files before making the backup. Another would be
to get a list of complete log files from both the live and backup
repositories and only delete those that are present in both lists.

5. backup removal race (not serious)
When deleting old backups multiple instances of hot-backup.py may
attempt to delete the same backup. I'm not a Python expert but I
think this is likely to result in some of the scripts returning an
error, thus erroneously indicating that the backup failed. The simple
solution of simply ignoring errors while deleting old backups is
probably not a good idea, it might lead to the underlying backup
storage filling up. I'm not sure what the best solution is, perhaps
some sort of lock file? If so then perhaps that lock file should also
be used when choosing the backup name?

-- 
Philip Martin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org