infra_wiki

Restore a site

Copy a kthx quick site's files back from the noncurrent object versions that the sites bucket keeps.

Use this runbook when a deploy or kthx rm lost files of a quick site. The bluenose-kthx-sites bucket keeps three noncurrent versions of each object for 30 days, so a file can come back for that long. A site's database is not in the bucket.

Before you start#

  • Sign in to gcloud as an account that may write the bluenose-kthx-sites bucket.
  • Know the site's name and the time of the deploy to undo.

Restore the files#

  1. List every version of the site's objects.

    gcloud storage ls --all-versions --long 'gs://bluenose-kthx-sites/<name>/**'

    Result: each line is a version, with its time and a #<generation> suffix.

  2. For each file to restore, pick the newest version from before the deploy.

  3. Copy that version over the live object.

    gcloud storage cp 'gs://bluenose-kthx-sites/<name>/<path>#<generation>' 'gs://bluenose-kthx-sites/<name>/<path>'
  4. If kthx rm deleted the site, restore its marker <name>/.kthx last. The copy keeps the owner in its metadata.

  5. Make sure the site serves the restored files.

    curl -s "https://<name>.kthx.dev/?cachebust=$(date +%s)"

    Result: the restored page, within about 10 seconds of the copy.

note

After kthx rm, the kthx server drops the site's database within 10 minutes. Restore a database brings back the kthx-db cluster, with every site's later writes lost.

If something goes wrong#

SymptomCauseAction
ls shows no older versionThe version is past 30 days, or was the fourth noncurrent oneDeploy the site again from its source.
The site answers its API with 404The marker is not restoredRestore <name>/.kthx.
cp answers 403The account may not write the bucketSign in as an account with object write access.

Edit on GitHub

↑↓ move ↵ open esc close