Fossil SCM
Added "Restoring From An Encrypted Backup" section to the new backup.md doc.
Commit
e0a38eb3eb67c7cfd1d62788c0384090f31f9e534911a61e5fd057f55000cd6e
Parent
e5ad07dcf645546…
1 file changed
+33
+33
| --- www/backup.md | ||
| +++ www/backup.md | ||
| @@ -181,10 +181,43 @@ | ||
| 181 | 181 | compression algorithm that takes less CPU power, such as [`lz4`][lz4]. |
| 182 | 182 | Changing up the compression algorithm also provides some |
| 183 | 183 | security-thru-obscurity, which is useless on its own, but it *is* a |
| 184 | 184 | useful adjunct to strong encryption. |
| 185 | 185 | |
| 186 | + | |
| 187 | +## Restoring From An Encrypted Backup | |
| 188 | + | |
| 189 | +The “restore” script for the above fragment is basically an inverse of | |
| 190 | +it, but it’s worth showing it because there are some subtleties to take | |
| 191 | +care of. If all variables defined in earlier scripts are available, then | |
| 192 | +restoration is: | |
| 193 | + | |
| 194 | +``` | |
| 195 | +openssl enc -d -aes-256-cbc -pbkdf2 -iter 52830 -pass pass:"$pass" -in "$gd" | | |
| 196 | + xz -d | sqlite3 ~/museum/restored-repo.fossil | |
| 197 | +``` | |
| 198 | + | |
| 199 | +We changed the `-e` to `-d` on the `openssl` command to get decryption, | |
| 200 | +and we changed the `-out` to `-in` so it reads from the encrypted backup | |
| 201 | +file and writes the result to stdout. | |
| 202 | + | |
| 203 | +The decompression step is trivial. | |
| 204 | + | |
| 205 | +The last change is tricky: we used `fossil sql` above to ensure that | |
| 206 | +we’re using the same version of SQLite to write the encrypted backup DB | |
| 207 | +as was used to maintain the repository, but unfortunately, we can’t get | |
| 208 | +the built-in SQLite shell to write a backup into an empty database. | |
| 209 | +Therefore, we have to either run the restoration against a | |
| 210 | +possibly-different version of SQLite and hope there are no | |
| 211 | +incompatibilities, or we have to go out of our way to build a matching | |
| 212 | +version of `sqlite3` before we can safely do the restoration. | |
| 213 | + | |
| 214 | +Keep in mind that Fossil often acts as a dogfooding project for SQLite, | |
| 215 | +making use of the latest features, so it is quite likely that a given | |
| 216 | +random `sqlite3` binary in your `PATH` may be unable to understand the | |
| 217 | +dump file created by the backup script! | |
| 218 | + | |
| 186 | 219 | [bu]: /help?cmd=backup |
| 187 | 220 | [grcp]: https://www.grc.com/passwords.htm |
| 188 | 221 | [hb]: https://brew.sh |
| 189 | 222 | [hbul]: https://docs.brew.sh/FAQ#what-does-keg-only-mean |
| 190 | 223 | [lz4]: https://lz4.github.io/lz4/ |
| 191 | 224 |
| --- www/backup.md | |
| +++ www/backup.md | |
| @@ -181,10 +181,43 @@ | |
| 181 | compression algorithm that takes less CPU power, such as [`lz4`][lz4]. |
| 182 | Changing up the compression algorithm also provides some |
| 183 | security-thru-obscurity, which is useless on its own, but it *is* a |
| 184 | useful adjunct to strong encryption. |
| 185 | |
| 186 | [bu]: /help?cmd=backup |
| 187 | [grcp]: https://www.grc.com/passwords.htm |
| 188 | [hb]: https://brew.sh |
| 189 | [hbul]: https://docs.brew.sh/FAQ#what-does-keg-only-mean |
| 190 | [lz4]: https://lz4.github.io/lz4/ |
| 191 |
| --- www/backup.md | |
| +++ www/backup.md | |
| @@ -181,10 +181,43 @@ | |
| 181 | compression algorithm that takes less CPU power, such as [`lz4`][lz4]. |
| 182 | Changing up the compression algorithm also provides some |
| 183 | security-thru-obscurity, which is useless on its own, but it *is* a |
| 184 | useful adjunct to strong encryption. |
| 185 | |
| 186 | |
| 187 | ## Restoring From An Encrypted Backup |
| 188 | |
| 189 | The “restore” script for the above fragment is basically an inverse of |
| 190 | it, but it’s worth showing it because there are some subtleties to take |
| 191 | care of. If all variables defined in earlier scripts are available, then |
| 192 | restoration is: |
| 193 | |
| 194 | ``` |
| 195 | openssl enc -d -aes-256-cbc -pbkdf2 -iter 52830 -pass pass:"$pass" -in "$gd" | |
| 196 | xz -d | sqlite3 ~/museum/restored-repo.fossil |
| 197 | ``` |
| 198 | |
| 199 | We changed the `-e` to `-d` on the `openssl` command to get decryption, |
| 200 | and we changed the `-out` to `-in` so it reads from the encrypted backup |
| 201 | file and writes the result to stdout. |
| 202 | |
| 203 | The decompression step is trivial. |
| 204 | |
| 205 | The last change is tricky: we used `fossil sql` above to ensure that |
| 206 | we’re using the same version of SQLite to write the encrypted backup DB |
| 207 | as was used to maintain the repository, but unfortunately, we can’t get |
| 208 | the built-in SQLite shell to write a backup into an empty database. |
| 209 | Therefore, we have to either run the restoration against a |
| 210 | possibly-different version of SQLite and hope there are no |
| 211 | incompatibilities, or we have to go out of our way to build a matching |
| 212 | version of `sqlite3` before we can safely do the restoration. |
| 213 | |
| 214 | Keep in mind that Fossil often acts as a dogfooding project for SQLite, |
| 215 | making use of the latest features, so it is quite likely that a given |
| 216 | random `sqlite3` binary in your `PATH` may be unable to understand the |
| 217 | dump file created by the backup script! |
| 218 | |
| 219 | [bu]: /help?cmd=backup |
| 220 | [grcp]: https://www.grc.com/passwords.htm |
| 221 | [hb]: https://brew.sh |
| 222 | [hbul]: https://docs.brew.sh/FAQ#what-does-keg-only-mean |
| 223 | [lz4]: https://lz4.github.io/lz4/ |
| 224 |