Fossil SCM
Using `fossil sql --no-repository` instead of `sqlite3` in the restore step of backup.md.
Commit
ff7cedfeec93a059769720a0ac6741cbc6940acccc908a61c4d654b87dca9199
Parent
e9b5a983cc80149…
1 file changed
+12
-13
+12
-13
| --- www/backup.md | ||
| +++ www/backup.md | ||
| @@ -202,11 +202,11 @@ | ||
| 202 | 202 | care of. If all variables defined in earlier scripts are available, then |
| 203 | 203 | restoration is: |
| 204 | 204 | |
| 205 | 205 | ``` |
| 206 | 206 | openssl enc -d -aes-256-cbc -pbkdf2 -iter 52830 -pass pass:"$pass" -in "$gd" | |
| 207 | - xz -d | sqlite3 ~/museum/restored-repo.fossil | |
| 207 | + xz -d | fossil --no-repository ~/museum/restored-repo.fossil | |
| 208 | 208 | ``` |
| 209 | 209 | |
| 210 | 210 | We changed the `-e` to `-d` on the `openssl` command to get decryption, |
| 211 | 211 | and we changed the `-out` to `-in` so it reads from the encrypted backup |
| 212 | 212 | file and writes the result to stdout. |
| @@ -213,23 +213,22 @@ | ||
| 213 | 213 | |
| 214 | 214 | The decompression step is trivial. |
| 215 | 215 | |
| 216 | 216 | The last change is tricky: we used `fossil sql` above to ensure that |
| 217 | 217 | we’re using the same version of SQLite to write the encrypted backup DB |
| 218 | -as was used to maintain the repository, but unfortunately, we can’t get | |
| 219 | -the built-in SQLite shell to write a backup into an empty database. | |
| 220 | -(As soon as it starts up, it goes looking for tables created by | |
| 221 | -`fossil init` and fails with an error.) | |
| 222 | -Therefore, we have to either run the restoration against a | |
| 223 | -possibly-different version of SQLite and hope there are no | |
| 224 | -incompatibilities, or we have to go out of our way to build a matching | |
| 225 | -version of `sqlite3` before we can safely do the restoration. | |
| 226 | - | |
| 227 | -Keep in mind that Fossil often acts as a dogfooding project for SQLite, | |
| 228 | -making use of the latest features, so it is quite likely that a given | |
| 218 | +as was used to maintain the repository. We must also do that on | |
| 219 | +restoration: | |
| 220 | +Fossil serves as a dogfooding project for SQLite, | |
| 221 | +often making use of the latest features, so it is quite likely that a given | |
| 229 | 222 | random `sqlite3` binary in your `PATH` will be unable to understand the |
| 230 | -file created by “`fossil sql .dump`”! | |
| 223 | +file created by “`fossil sql .dump`”! The tricky bit is, you can’t just | |
| 224 | +pipe the decrpted SQL dump into `fossil sql`, because on startup, Fossil | |
| 225 | +normally goes looking for tables created by `fossil init`, and it won’t | |
| 226 | +find them in a newly-created repo DB. We get around this by passing | |
| 227 | +the `--no-repository` flag, which suppresses this behavior. Doing it | |
| 228 | +this way saves you from needing to go and build a matching version of | |
| 229 | +`sqlite3` just to restore the backup. | |
| 231 | 230 | |
| 232 | 231 | [bu]: /help?cmd=backup |
| 233 | 232 | [grcp]: https://www.grc.com/passwords.htm |
| 234 | 233 | [hb]: https://brew.sh |
| 235 | 234 | [hbul]: https://docs.brew.sh/FAQ#what-does-keg-only-mean |
| 236 | 235 |
| --- www/backup.md | |
| +++ www/backup.md | |
| @@ -202,11 +202,11 @@ | |
| 202 | care of. If all variables defined in earlier scripts are available, then |
| 203 | restoration is: |
| 204 | |
| 205 | ``` |
| 206 | openssl enc -d -aes-256-cbc -pbkdf2 -iter 52830 -pass pass:"$pass" -in "$gd" | |
| 207 | xz -d | sqlite3 ~/museum/restored-repo.fossil |
| 208 | ``` |
| 209 | |
| 210 | We changed the `-e` to `-d` on the `openssl` command to get decryption, |
| 211 | and we changed the `-out` to `-in` so it reads from the encrypted backup |
| 212 | file and writes the result to stdout. |
| @@ -213,23 +213,22 @@ | |
| 213 | |
| 214 | The decompression step is trivial. |
| 215 | |
| 216 | The last change is tricky: we used `fossil sql` above to ensure that |
| 217 | we’re using the same version of SQLite to write the encrypted backup DB |
| 218 | as was used to maintain the repository, but unfortunately, we can’t get |
| 219 | the built-in SQLite shell to write a backup into an empty database. |
| 220 | (As soon as it starts up, it goes looking for tables created by |
| 221 | `fossil init` and fails with an error.) |
| 222 | Therefore, we have to either run the restoration against a |
| 223 | possibly-different version of SQLite and hope there are no |
| 224 | incompatibilities, or we have to go out of our way to build a matching |
| 225 | version of `sqlite3` before we can safely do the restoration. |
| 226 | |
| 227 | Keep in mind that Fossil often acts as a dogfooding project for SQLite, |
| 228 | making use of the latest features, so it is quite likely that a given |
| 229 | random `sqlite3` binary in your `PATH` will be unable to understand the |
| 230 | file created by “`fossil sql .dump`”! |
| 231 | |
| 232 | [bu]: /help?cmd=backup |
| 233 | [grcp]: https://www.grc.com/passwords.htm |
| 234 | [hb]: https://brew.sh |
| 235 | [hbul]: https://docs.brew.sh/FAQ#what-does-keg-only-mean |
| 236 |
| --- www/backup.md | |
| +++ www/backup.md | |
| @@ -202,11 +202,11 @@ | |
| 202 | care of. If all variables defined in earlier scripts are available, then |
| 203 | restoration is: |
| 204 | |
| 205 | ``` |
| 206 | openssl enc -d -aes-256-cbc -pbkdf2 -iter 52830 -pass pass:"$pass" -in "$gd" | |
| 207 | xz -d | fossil --no-repository ~/museum/restored-repo.fossil |
| 208 | ``` |
| 209 | |
| 210 | We changed the `-e` to `-d` on the `openssl` command to get decryption, |
| 211 | and we changed the `-out` to `-in` so it reads from the encrypted backup |
| 212 | file and writes the result to stdout. |
| @@ -213,23 +213,22 @@ | |
| 213 | |
| 214 | The decompression step is trivial. |
| 215 | |
| 216 | The last change is tricky: we used `fossil sql` above to ensure that |
| 217 | we’re using the same version of SQLite to write the encrypted backup DB |
| 218 | as was used to maintain the repository. We must also do that on |
| 219 | restoration: |
| 220 | Fossil serves as a dogfooding project for SQLite, |
| 221 | often making use of the latest features, so it is quite likely that a given |
| 222 | random `sqlite3` binary in your `PATH` will be unable to understand the |
| 223 | file created by “`fossil sql .dump`”! The tricky bit is, you can’t just |
| 224 | pipe the decrpted SQL dump into `fossil sql`, because on startup, Fossil |
| 225 | normally goes looking for tables created by `fossil init`, and it won’t |
| 226 | find them in a newly-created repo DB. We get around this by passing |
| 227 | the `--no-repository` flag, which suppresses this behavior. Doing it |
| 228 | this way saves you from needing to go and build a matching version of |
| 229 | `sqlite3` just to restore the backup. |
| 230 | |
| 231 | [bu]: /help?cmd=backup |
| 232 | [grcp]: https://www.grc.com/passwords.htm |
| 233 | [hb]: https://brew.sh |
| 234 | [hbul]: https://docs.brew.sh/FAQ#what-does-keg-only-mean |
| 235 |