| @@ -489,8 +489,11 @@ restic credentials), so verifying an encrypted archive happens there |
| 489 | 489 | or on a restore host. |
| 490 | 490 | |
| 491 | 491 | Restore: extract into an empty directory, point =server.root= at it, |
| 492 | | start gitbayd. Host keys are preserved, so clients keep their |
| 493 | | known_hosts entries; hooks regenerate at startup. |
| 492 | restore =server.secret_key_file= from its own copy (mode 0600, owned |
| 493 | by the account gitbayd runs as), then start gitbayd. No archive carries |
| 494 | the key file, and without it gitbayd refuses to start. Host keys are |
| 495 | preserved, so clients keep their known_hosts entries; hooks regenerate |
| 496 | at startup. |
| 494 | 497 | |
| 495 | 498 | ** Schedule and recovery point |
| 496 | 499 | |
| @@ -518,8 +521,10 @@ too. |
| 518 | 521 | ** Offsite copies |
| 519 | 522 | |
| 520 | 523 | bay1 also takes a nightly restic snapshot of =/var/lib/gitbay= and |
| 521 | | =/var/lib/gitbay-stage= (the staged database copy) to an S3 bucket at |
| 522 | | Scaleway, with a key that can only add snapshots. The key that can |
| 524 | =/var/lib/gitbay-stage= (a database copy and =config.toml=, staged |
| 525 | there) to an S3 bucket at Scaleway, with a key that can only add |
| 526 | snapshots. Nothing else under =/etc/gitbay= is in it: not the secret |
| 527 | key file, not =apns.p8=. The key that can |
| 523 | 528 | remove them lives on the operator's machine, in |
| 524 | 529 | =~/.config/gitbay/offsite.env=, and never on bay1: a compromised host |
| 525 | 530 | cannot destroy its own history. Forgetting, pruning and rewriting all |
| @@ -568,7 +573,10 @@ each value prefixed with the id of the key that sealed it |
| 568 | 573 | =server.root=, and therefore in neither the local archives nor the |
| 569 | 574 | main restic repository. It must be copied off the host separately; |
| 570 | 575 | without it a restored database's secrets cannot be opened, and |
| 571 | | gitbayd refuses to start against them. |
| 576 | gitbayd refuses to start against them. A separate restic repository |
| 577 | for it and =apns.p8= is planned (runbook D of the data-at-rest plan) |
| 578 | and not yet in place, so today the only off-host copy is one the |
| 579 | operator makes by hand after =init= and after every =rotate=. |
| 572 | 580 | |
| 573 | 581 | #+begin_src sh |
| 574 | 582 | gitbayd admin secrets init # once; deploy/install.sh does it on first install |
| @@ -598,9 +606,10 @@ backup code (=cmd/gitbayd/backup.go=, the offsite job), and recorded |
| 598 | 606 | below. The disaster it rehearses is losing bay1, so the local archives |
| 599 | 607 | are gone with it and the sources are the main offsite restic |
| 600 | 608 | repository (repositories, LFS, the staged database, =config.toml=), |
| 601 | | the keys repository (=secret.key=, =apns.p8=), and the operator's |
| 602 | | password manager (=offsite.env=, the keys repository's password and |
| 603 | | token, =backup-identity.txt=). The steps are in the data-at-rest |
| 609 | the off-host copy of =secret.key= and =apns.p8= (a keys repository once |
| 610 | runbook D creates it; until then the operator's hand-made copy), and |
| 611 | the operator's password manager (=offsite.env=, the keys repository's |
| 612 | password and token once it exists, =backup-identity.txt=). The steps are in the data-at-rest |
| 604 | 613 | plan's operator runbook |
| 605 | 614 | (=docs/plans/2026-09-27-data-at-rest-and-backup.md=). |
| 606 | 615 | |