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