Fossil SCM
Removed horizontal rules in backup doc used to offset the bigger code blocks. Between the new light-gray background and the indents, they're adding noise more than helping break the page up.
Commit
6b520900c9b3c2997d84c73a772a9cd8a5e5a5478aa6f6e7ba76fe79370afe0e
Parent
1e0c0d0414bbfaa…
1 file changed
-6
-6
| --- www/backup.md | ||
| +++ www/backup.md | ||
| @@ -136,21 +136,17 @@ | ||
| 136 | 136 | The following script solves most of the above problems for the use case |
| 137 | 137 | where you want a *nearly-complete* clone of the remote repository using nothing |
| 138 | 138 | but the normal Fossil sync protocol. It only does so if you are logged into |
| 139 | 139 | the remote as a user with Setup capability, however. |
| 140 | 140 | |
| ----- | ||
| 141 | - | |
| 142 | 141 | ``` shell |
| 143 | 142 | #!/bin/sh |
| 144 | 143 | fossil sync --unversioned |
| 145 | 144 | fossil configuration pull all |
| 146 | 145 | fossil rebuild |
| 147 | 146 | ``` |
| 148 | 147 | |
| ----- | ||
| 149 | - | |
| 150 | 148 | The last step is needed to ensure that shunned artifacts on the remote |
| 151 | 149 | are removed from the local clone. The second step includes |
| 152 | 150 | `fossil conf pull shun`, but until those artifacts are actually rebuilt |
| 153 | 151 | out of existence, your backup will be “more than complete” in the sense |
| 154 | 152 | that it will continue to have information that the remote says should |
| @@ -170,21 +166,17 @@ | ||
| 170 | 166 | locking and transaction isolation, allowing the user to safely back up an in-use |
| 171 | 167 | repository. |
| 172 | 168 | |
| 173 | 169 | If you have SSH access to the remote server, something like this will work: |
| 174 | 170 | |
| ----- | ||
| 175 | - | |
| 176 | 171 | ``` shell |
| 177 | 172 | #!/bin/bash |
| 178 | 173 | bf=repo-$(date +%Y-%m-%d).fossil |
| 179 | 174 | ssh example.com "cd museum ; fossil backup -R repo.fossil backups/$bf" && |
| 180 | 175 | scp example.com:museum/backups/$bf ~/museum/backups |
| 181 | 176 | ``` |
| 182 | 177 | |
| ----- | ||
| 183 | - | |
| 184 | 178 | Beware that this method does not solve [the intransitive sync |
| 185 | 179 | problem](#ait), in and of itself: if you do a SQL-level backup of a |
| 186 | 180 | stale repo DB, you have a *stale backup!* You should therefore run this |
| 187 | 181 | on every node that may need to serve as a backup so that at least *one* |
| 188 | 182 | of the backups is also up-to-date. |
| @@ -198,22 +190,18 @@ | ||
| 198 | 190 | or Microsoft OneDrive, where you don’t fully trust the service not to |
| 199 | 191 | leak your information. This addition to the prior scripts will encrypt |
| 200 | 192 | the resulting backup in such a way that the cloud copy is a useless blob |
| 201 | 193 | of noise to anyone without the key: |
| 202 | 194 | |
| ----- | ||
| 203 | - | |
| 204 | 195 | ```shell |
| 205 | 196 | iter=152830 |
| 206 | 197 | pass="h8TixP6Mt6edJ3d6COaexiiFlvAM54auF2AjT7ZYYn" |
| 207 | 198 | gd="$HOME/Google Drive/Fossil Backups/$bf.xz.enc" |
| 208 | 199 | fossil sql -R ~/museum/backups/"$bf" .dump | xz -9 | |
| 209 | 200 | openssl enc -e -aes-256-cbc -pbkdf2 -iter $iter -pass pass:"$pass" -out "$gd" |
| 210 | 201 | ``` |
| 211 | 202 | |
| ----- | ||
| 212 | - | |
| 213 | 203 | If you’re adding this to the first script above, remove the |
| 214 | 204 | “`-R repo-name`” bit so you get a dump of the repository backing the |
| 215 | 205 | current working directory. |
| 216 | 206 | |
| 217 | 207 | Change the `pass` value to some other long random string, and change the |
| 218 | 208 |
| --- www/backup.md | |
| +++ www/backup.md | |
| @@ -136,21 +136,17 @@ | |
| 136 | The following script solves most of the above problems for the use case |
| 137 | where you want a *nearly-complete* clone of the remote repository using nothing |
| 138 | but the normal Fossil sync protocol. It only does so if you are logged into |
| 139 | the remote as a user with Setup capability, however. |
| 140 | |
| ----- | |
| 141 | |
| 142 | ``` shell |
| 143 | #!/bin/sh |
| 144 | fossil sync --unversioned |
| 145 | fossil configuration pull all |
| 146 | fossil rebuild |
| 147 | ``` |
| 148 | |
| ----- | |
| 149 | |
| 150 | The last step is needed to ensure that shunned artifacts on the remote |
| 151 | are removed from the local clone. The second step includes |
| 152 | `fossil conf pull shun`, but until those artifacts are actually rebuilt |
| 153 | out of existence, your backup will be “more than complete” in the sense |
| 154 | that it will continue to have information that the remote says should |
| @@ -170,21 +166,17 @@ | |
| 170 | locking and transaction isolation, allowing the user to safely back up an in-use |
| 171 | repository. |
| 172 | |
| 173 | If you have SSH access to the remote server, something like this will work: |
| 174 | |
| ----- | |
| 175 | |
| 176 | ``` shell |
| 177 | #!/bin/bash |
| 178 | bf=repo-$(date +%Y-%m-%d).fossil |
| 179 | ssh example.com "cd museum ; fossil backup -R repo.fossil backups/$bf" && |
| 180 | scp example.com:museum/backups/$bf ~/museum/backups |
| 181 | ``` |
| 182 | |
| ----- | |
| 183 | |
| 184 | Beware that this method does not solve [the intransitive sync |
| 185 | problem](#ait), in and of itself: if you do a SQL-level backup of a |
| 186 | stale repo DB, you have a *stale backup!* You should therefore run this |
| 187 | on every node that may need to serve as a backup so that at least *one* |
| 188 | of the backups is also up-to-date. |
| @@ -198,22 +190,18 @@ | |
| 198 | or Microsoft OneDrive, where you don’t fully trust the service not to |
| 199 | leak your information. This addition to the prior scripts will encrypt |
| 200 | the resulting backup in such a way that the cloud copy is a useless blob |
| 201 | of noise to anyone without the key: |
| 202 | |
| ----- | |
| 203 | |
| 204 | ```shell |
| 205 | iter=152830 |
| 206 | pass="h8TixP6Mt6edJ3d6COaexiiFlvAM54auF2AjT7ZYYn" |
| 207 | gd="$HOME/Google Drive/Fossil Backups/$bf.xz.enc" |
| 208 | fossil sql -R ~/museum/backups/"$bf" .dump | xz -9 | |
| 209 | openssl enc -e -aes-256-cbc -pbkdf2 -iter $iter -pass pass:"$pass" -out "$gd" |
| 210 | ``` |
| 211 | |
| ----- | |
| 212 | |
| 213 | If you’re adding this to the first script above, remove the |
| 214 | “`-R repo-name`” bit so you get a dump of the repository backing the |
| 215 | current working directory. |
| 216 | |
| 217 | Change the `pass` value to some other long random string, and change the |
| 218 |
| --- www/backup.md | |
| +++ www/backup.md | |
| @@ -136,21 +136,17 @@ | |
| 136 | The following script solves most of the above problems for the use case |
| 137 | where you want a *nearly-complete* clone of the remote repository using nothing |
| 138 | but the normal Fossil sync protocol. It only does so if you are logged into |
| 139 | the remote as a user with Setup capability, however. |
| 140 | |
| ----- | |
| 141 | ``` shell |
| 142 | #!/bin/sh |
| 143 | fossil sync --unversioned |
| 144 | fossil configuration pull all |
| 145 | fossil rebuild |
| 146 | ``` |
| 147 | |
| ----- | |
| 148 | The last step is needed to ensure that shunned artifacts on the remote |
| 149 | are removed from the local clone. The second step includes |
| 150 | `fossil conf pull shun`, but until those artifacts are actually rebuilt |
| 151 | out of existence, your backup will be “more than complete” in the sense |
| 152 | that it will continue to have information that the remote says should |
| @@ -170,21 +166,17 @@ | |
| 166 | locking and transaction isolation, allowing the user to safely back up an in-use |
| 167 | repository. |
| 168 | |
| 169 | If you have SSH access to the remote server, something like this will work: |
| 170 | |
| ----- | |
| 171 | ``` shell |
| 172 | #!/bin/bash |
| 173 | bf=repo-$(date +%Y-%m-%d).fossil |
| 174 | ssh example.com "cd museum ; fossil backup -R repo.fossil backups/$bf" && |
| 175 | scp example.com:museum/backups/$bf ~/museum/backups |
| 176 | ``` |
| 177 | |
| ----- | |
| 178 | Beware that this method does not solve [the intransitive sync |
| 179 | problem](#ait), in and of itself: if you do a SQL-level backup of a |
| 180 | stale repo DB, you have a *stale backup!* You should therefore run this |
| 181 | on every node that may need to serve as a backup so that at least *one* |
| 182 | of the backups is also up-to-date. |
| @@ -198,22 +190,18 @@ | |
| 190 | or Microsoft OneDrive, where you don’t fully trust the service not to |
| 191 | leak your information. This addition to the prior scripts will encrypt |
| 192 | the resulting backup in such a way that the cloud copy is a useless blob |
| 193 | of noise to anyone without the key: |
| 194 | |
| ----- | |
| 195 | ```shell |
| 196 | iter=152830 |
| 197 | pass="h8TixP6Mt6edJ3d6COaexiiFlvAM54auF2AjT7ZYYn" |
| 198 | gd="$HOME/Google Drive/Fossil Backups/$bf.xz.enc" |
| 199 | fossil sql -R ~/museum/backups/"$bf" .dump | xz -9 | |
| 200 | openssl enc -e -aes-256-cbc -pbkdf2 -iter $iter -pass pass:"$pass" -out "$gd" |
| 201 | ``` |
| 202 | |
| ----- | |
| 203 | If you’re adding this to the first script above, remove the |
| 204 | “`-R repo-name`” bit so you get a dump of the repository backing the |
| 205 | current working directory. |
| 206 | |
| 207 | Change the `pass` value to some other long random string, and change the |
| 208 |