On 7/20/18, Florian Balmer <florian.bal...@gmail.com> wrote: > But what is a good > strategy to minimize backup traffic, if repository databases change > that often? >
Don't backup by copying the database file (which is not safe to do anyhow, unless you shutdown Fossil during the copy, because otherwise the database file might change while it is being copied, resulting in a corrupt copy.). Instead, create your backups by cloning and syncing. That is what DVCSes are designed to do. The canonical Fossil self-hosting repository, and the SQLite source repository that Fossil was created to manage, are both backed up this way. There are three separate servers, each in separate geographically distributed data centers, managed by two indenpendent ISPs. These repos are all synced with one another automatically using a cron-job. One cool bonus feature of this approach is that the 'backups" are live repositories, that can be directly accessed (as https://www2.fossil-scm.org/ and httpss://www3.fossil-scm.org/site.cgi) so it is easy to verify that the backups are really happening and that they are correct. -- D. Richard Hipp d...@sqlite.org _______________________________________________ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
