Fossil SCM
A few small refinements to the new backup doc.
Commit
ea57a2f72300e19612ca12dc3375f08c52263e6ad63a197b4b11a863b32ce4dd
Parent
3ddc1d9458b1054…
1 file changed
+13
-6
+13
-6
| --- www/backup.md | ||
| +++ www/backup.md | ||
| @@ -3,11 +3,12 @@ | ||
| 3 | 3 | Simply cloning a Fossil repository does not necessarily create a |
| 4 | 4 | *complete* backup of the remote repository’s contents. With an existing |
| 5 | 5 | clone, Fossil’s autosync feature isn’t enough to keep that clone fully |
| 6 | 6 | up-to-date in a backup failover sense. This document explains what your |
| 7 | 7 | clone may be missing and how to ensure that it is complete for cases |
| 8 | -where you intend to provide a complete backup of the remote. | |
| 8 | +where you wish to have a backup suitable for replacing it without data | |
| 9 | +loss, should the need arise. | |
| 9 | 10 | |
| 10 | 11 | |
| 11 | 12 | |
| 12 | 13 | ## Sensitive Information |
| 13 | 14 | |
| @@ -85,14 +86,15 @@ | ||
| 85 | 86 | [private branches][pbr], on purpose. It may also miss other info on the |
| 86 | 87 | remote, such as SQL-level customizations that the sync protocol can’t |
| 87 | 88 | see. (Some [ticket system customization][tkt] schemes do this.) You can |
| 88 | 89 | solve such problems if you have access to the remote server, which |
| 89 | 90 | allows you to get a SQL-level backup. This requires Fossil 2.12 or |
| 90 | -newer, which added [the `backup` command][bu]. | |
| 91 | +newer, which added [the `backup` command][bu], which takes care of | |
| 92 | +locking and transaction isolation to allow backing up an in-use | |
| 93 | +repository. | |
| 91 | 94 | |
| 92 | -You can get an off-machine SQL-level backup of a Fossil repository on | |
| 93 | -a remote server over SSH like so: | |
| 95 | +If you have SSH access to the remote server, something like this will work: | |
| 94 | 96 | |
| 95 | 97 | ---- |
| 96 | 98 | |
| 97 | 99 | ``` shell |
| 98 | 100 | #!/bin/bash |
| @@ -104,11 +106,11 @@ | ||
| 104 | 106 | |
| 105 | 107 | ## Encrypted Off-Site Backups |
| 106 | 108 | |
| 107 | 109 | A useful refinement that you can apply to both methods above is |
| 108 | 110 | encrypted off-site backups. You may wish to store backups of your |
| 109 | -repositories off-site on services such as Dropbox, Google Drive, iCloud, | |
| 111 | +repositories off-site on a service such as Dropbox, Google Drive, iCloud, | |
| 110 | 112 | or Microsoft OneDrive, where you don’t fully trust the service not to |
| 111 | 113 | leak your information. This addition to the prior scripts will encrypt |
| 112 | 114 | the resulting backup in such a way that the cloud copy is a useless blob |
| 113 | 115 | of noise to anyone without the key: |
| 114 | 116 | |
| @@ -144,17 +146,22 @@ | ||
| 144 | 146 | the first is [here][grcp], and for the second, [here][rint]. |
| 145 | 147 | |
| 146 | 148 | Compressing the data before encrypting it removes redundancies that can |
| 147 | 149 | make decryption easier, and it results in a smaller backup than you get |
| 148 | 150 | with the previous script alone, at the expense of a lot of CPU time |
| 149 | -during the backup. | |
| 151 | +during the backup. You may wish to switch to a less space-efficient | |
| 152 | +compression algorithm that takes less CPU power, such as [`lz4`][lz4]. | |
| 153 | +Changing up the compression algorithm also provides some | |
| 154 | +security-thru-obscurity, which is useless on its own, but it *is* a | |
| 155 | +useful adjunct to strong encryption. | |
| 150 | 156 | |
| 151 | 157 | [bu]: /help?cmd=backup |
| 152 | 158 | [grcp]: https://www.grc.com/passwords.htm |
| 153 | 159 | [hb]: https://brew.sh |
| 154 | 160 | [hbul]: https://docs.brew.sh/FAQ#what-does-keg-only-mean |
| 161 | +[lz4]: https://lz4.github.io/lz4/ | |
| 155 | 162 | [pbr]: ./private.wiki |
| 156 | 163 | [rint]: https://www.random.org/integers/?num=1&min=10000&max=100000&col=5&base=10&format=html&rnd=new |
| 157 | 164 | [setup]: ./caps/admin-v-setup.md#apsu |
| 158 | 165 | [shun]: ./shunning.wiki |
| 159 | 166 | [tkt]: ./tickets.wiki |
| 160 | 167 | [uv]: ./unvers.wiki |
| 161 | 168 |
| --- www/backup.md | |
| +++ www/backup.md | |
| @@ -3,11 +3,12 @@ | |
| 3 | Simply cloning a Fossil repository does not necessarily create a |
| 4 | *complete* backup of the remote repository’s contents. With an existing |
| 5 | clone, Fossil’s autosync feature isn’t enough to keep that clone fully |
| 6 | up-to-date in a backup failover sense. This document explains what your |
| 7 | clone may be missing and how to ensure that it is complete for cases |
| 8 | where you intend to provide a complete backup of the remote. |
| 9 | |
| 10 | |
| 11 | |
| 12 | ## Sensitive Information |
| 13 | |
| @@ -85,14 +86,15 @@ | |
| 85 | [private branches][pbr], on purpose. It may also miss other info on the |
| 86 | remote, such as SQL-level customizations that the sync protocol can’t |
| 87 | see. (Some [ticket system customization][tkt] schemes do this.) You can |
| 88 | solve such problems if you have access to the remote server, which |
| 89 | allows you to get a SQL-level backup. This requires Fossil 2.12 or |
| 90 | newer, which added [the `backup` command][bu]. |
| 91 | |
| 92 | You can get an off-machine SQL-level backup of a Fossil repository on |
| 93 | a remote server over SSH like so: |
| 94 | |
| 95 | ---- |
| 96 | |
| 97 | ``` shell |
| 98 | #!/bin/bash |
| @@ -104,11 +106,11 @@ | |
| 104 | |
| 105 | ## Encrypted Off-Site Backups |
| 106 | |
| 107 | A useful refinement that you can apply to both methods above is |
| 108 | encrypted off-site backups. You may wish to store backups of your |
| 109 | repositories off-site on services such as Dropbox, Google Drive, iCloud, |
| 110 | or Microsoft OneDrive, where you don’t fully trust the service not to |
| 111 | leak your information. This addition to the prior scripts will encrypt |
| 112 | the resulting backup in such a way that the cloud copy is a useless blob |
| 113 | of noise to anyone without the key: |
| 114 | |
| @@ -144,17 +146,22 @@ | |
| 144 | the first is [here][grcp], and for the second, [here][rint]. |
| 145 | |
| 146 | Compressing the data before encrypting it removes redundancies that can |
| 147 | make decryption easier, and it results in a smaller backup than you get |
| 148 | with the previous script alone, at the expense of a lot of CPU time |
| 149 | during the backup. |
| 150 | |
| 151 | [bu]: /help?cmd=backup |
| 152 | [grcp]: https://www.grc.com/passwords.htm |
| 153 | [hb]: https://brew.sh |
| 154 | [hbul]: https://docs.brew.sh/FAQ#what-does-keg-only-mean |
| 155 | [pbr]: ./private.wiki |
| 156 | [rint]: https://www.random.org/integers/?num=1&min=10000&max=100000&col=5&base=10&format=html&rnd=new |
| 157 | [setup]: ./caps/admin-v-setup.md#apsu |
| 158 | [shun]: ./shunning.wiki |
| 159 | [tkt]: ./tickets.wiki |
| 160 | [uv]: ./unvers.wiki |
| 161 |
| --- www/backup.md | |
| +++ www/backup.md | |
| @@ -3,11 +3,12 @@ | |
| 3 | Simply cloning a Fossil repository does not necessarily create a |
| 4 | *complete* backup of the remote repository’s contents. With an existing |
| 5 | clone, Fossil’s autosync feature isn’t enough to keep that clone fully |
| 6 | up-to-date in a backup failover sense. This document explains what your |
| 7 | clone may be missing and how to ensure that it is complete for cases |
| 8 | where you wish to have a backup suitable for replacing it without data |
| 9 | loss, should the need arise. |
| 10 | |
| 11 | |
| 12 | |
| 13 | ## Sensitive Information |
| 14 | |
| @@ -85,14 +86,15 @@ | |
| 86 | [private branches][pbr], on purpose. It may also miss other info on the |
| 87 | remote, such as SQL-level customizations that the sync protocol can’t |
| 88 | see. (Some [ticket system customization][tkt] schemes do this.) You can |
| 89 | solve such problems if you have access to the remote server, which |
| 90 | allows you to get a SQL-level backup. This requires Fossil 2.12 or |
| 91 | newer, which added [the `backup` command][bu], which takes care of |
| 92 | locking and transaction isolation to allow backing up an in-use |
| 93 | repository. |
| 94 | |
| 95 | If you have SSH access to the remote server, something like this will work: |
| 96 | |
| 97 | ---- |
| 98 | |
| 99 | ``` shell |
| 100 | #!/bin/bash |
| @@ -104,11 +106,11 @@ | |
| 106 | |
| 107 | ## Encrypted Off-Site Backups |
| 108 | |
| 109 | A useful refinement that you can apply to both methods above is |
| 110 | encrypted off-site backups. You may wish to store backups of your |
| 111 | repositories off-site on a service such as Dropbox, Google Drive, iCloud, |
| 112 | or Microsoft OneDrive, where you don’t fully trust the service not to |
| 113 | leak your information. This addition to the prior scripts will encrypt |
| 114 | the resulting backup in such a way that the cloud copy is a useless blob |
| 115 | of noise to anyone without the key: |
| 116 | |
| @@ -144,17 +146,22 @@ | |
| 146 | the first is [here][grcp], and for the second, [here][rint]. |
| 147 | |
| 148 | Compressing the data before encrypting it removes redundancies that can |
| 149 | make decryption easier, and it results in a smaller backup than you get |
| 150 | with the previous script alone, at the expense of a lot of CPU time |
| 151 | during the backup. You may wish to switch to a less space-efficient |
| 152 | compression algorithm that takes less CPU power, such as [`lz4`][lz4]. |
| 153 | Changing up the compression algorithm also provides some |
| 154 | security-thru-obscurity, which is useless on its own, but it *is* a |
| 155 | useful adjunct to strong encryption. |
| 156 | |
| 157 | [bu]: /help?cmd=backup |
| 158 | [grcp]: https://www.grc.com/passwords.htm |
| 159 | [hb]: https://brew.sh |
| 160 | [hbul]: https://docs.brew.sh/FAQ#what-does-keg-only-mean |
| 161 | [lz4]: https://lz4.github.io/lz4/ |
| 162 | [pbr]: ./private.wiki |
| 163 | [rint]: https://www.random.org/integers/?num=1&min=10000&max=100000&col=5&base=10&format=html&rnd=new |
| 164 | [setup]: ./caps/admin-v-setup.md#apsu |
| 165 | [shun]: ./shunning.wiki |
| 166 | [tkt]: ./tickets.wiki |
| 167 | [uv]: ./unvers.wiki |
| 168 |