Richard Hipp:

> ... create your backups by cloning and syncing ...

Thank you for your comments.

I see, this completely makes sense.

The process of "restoring" a repository from backup would include
copying database files, as syncing from backup → original might not
work if something's gone awry with the original. My main concern here
is that the cloned backup really includes everything from the original
(configuration, etc.). But hearing again (haven't you already outlined
the "cloning as backup strategy" recently, on this list?) that it
works for the experts should give me the faith to trust it.

Backing up "hot" databases is currently not a concern with my private,
traditional-style CGI-served repositories.

I would like to have some "rotating" backup, with a way to go back
certain steps with the complete repository, i.e. day-by-day, for up to
one week, so I could catch the "last good" if I notice something
wrong. Copying and replacing duplicate files with hard-links is an
extremely straight forward and space efficient process to achieve

I will try the same with cloning new (some extra logic required) and
syncing existing repositories. But it may not be possible to detect
unchanged / duplicate repository database files, like this, as some
internally stored last sync or URL last access time stamps might
always result in a different database file, I assume.

fossil-users mailing list

Reply via email to