Fossil

Diff
Login

Differences From Artifact [94e1392a5b]:

To Artifact [bb34b195cd]:


1
2
3
4
5
6
7
8
9


10

11




12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29

30
31
32
33
34
35
36
# Backing Up a Remote Fossil Repository

Simply cloning a Fossil repository does not necessarily create a
*complete* backup of the remote repositorys contents. With an existing
clone, Fossil’s autosync feature isn’t enough to keep that clone fully
up-to-date in a backup failover sense. This document explains what your
clone may be missing and how to ensure that it is complete for cases
where you wish to have a backup suitable for replacing it without data
loss, should the need arise.










## Sensitive Information

Fossil purposefully does not clone certain sensitive information unless
you’re logged in with [setup] capability. As an example, a local clone
may have a different `user` table than the remote, because only the
Setup user is allowed to see the full version for privacy and security
reasons.


## Configuration Drift

Fossil allows the local configuration in certain areas to differ from
that of the remote. With the exception of the prior item, you get a copy
of these configuration areas on initial clone, but after that, some
remote configuration changes don’t sync down automatically, such as the
remote’s skin. You have to ask for updates to these configuration areas
explicitly.



## Private Branches

The very nature of Fossil’s [private branch feature][pbr] ensures that
remote clones don’t get a copy of those branches. Normally this is
exactly what you want, but in the case of making backups, you probably


|
|
|
|
<
|
|
>
>

>

>
>
>
>
















|
|
>







1
2
3
4
5
6

7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
# Backing Up a Remote Fossil Repository

One of the great benefits of Fossil and other [distributed version control systems][dvcs]
is that cloning a repository makes a backup.  So if you are running a project with multiple
developers who share their work using a [central server][server] and the server hardware
catches fire or otherwise becomes unavailable, the clones of the repository on each developer

workstation serve as a suitable backup.

[dvcs]: wikipedia:/wiki/Distributed_version_control
[server]: ./server/whyuseaserver.wiki

Mostly.

It turns out not everything in a Fossil repository is copied via clone.  A clone
protects all of the checked in code.  But a Fossil repository typically contains
other useful information that is not always shared as part of a clone, and might need
to be backed up separately.  To wit:

## Sensitive Information

Fossil purposefully does not clone certain sensitive information unless
you’re logged in with [setup] capability. As an example, a local clone
may have a different `user` table than the remote, because only the
Setup user is allowed to see the full version for privacy and security
reasons.


## Configuration Drift

Fossil allows the local configuration in certain areas to differ from
that of the remote. With the exception of the prior item, you get a copy
of these configuration areas on initial clone, but after that, some
remote configuration changes don’t sync down automatically, such as the
remote’s skin. You can ask for updates by running the
[`fossil config pull skiin`](./help?cmd=config) if you want, but that
does not happen automatically during the course of normal development.


## Private Branches

The very nature of Fossil’s [private branch feature][pbr] ensures that
remote clones don’t get a copy of those branches. Normally this is
exactly what you want, but in the case of making backups, you probably