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 this. 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. --Florian _______________________________________________ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
