Vladimir Berezniker <email@example.com> writes:
> D.J. Heap wrote:
>> There's still the nasty little race in here where a log file that
>> wasn't backed up could be deleted, right? Like when the recovery
>> step takes a while and another commit comes in -- the new hotbackup
>> hasn't had time to copy yet, the current one finishes recovery and
>> starts whacking log files that it may not have copied.
>> I think that can be fixed by making sure only the log files that
>> were copied in step 3 are deleted in step 6 -- don't delete
>> everything db_archive reports, just the union of what it reports and
>> what we copied...
>> Or am I missing something?
> I have mentioned this in about 3 emails, and provided hypothetical
> scenario how it could happen. However, I have not gotten a response
> as of yet. I guess this would only be applicable when total
> corruption occurs, so that all logs from the point of the previous
> good backup have to be replayed.
I agree, I think it's a real bug.
> I also offered to create a builtin hotcopy command and have not
> gotten much of a response on that either. However, I did see the
> email about the fact how everyone wants to add new exciting features
> to subversion and developers are stuck finding and fixing bugs.
> Since, after looking through bite-sized issues, I could not find a
> single one that I could work on. I decided it would be inappropriate
> for me to keep pushing the hotcopy thing.
The fact that our current backup script has a problem indicates that
it's possible to get the backup procedure wrong. I like the idea of
having a standard, robust, reliable method of making a hot backup.
The question is whether it is better to script it, or to make it a
standard command. Scripting has the advantage that it can more easily
be customised, but that also allows it to be broken.
On the whole I am in favour of an 'svnadmin copy' command.
To unsubscribe, e-mail: firstname.lastname@example.org
For additional commands, e-mail: email@example.com
Received on Wed Aug 27 20:58:09 2003