Dumping Keys

It can be useful to be able to generate current dumps of the set of keys known to the SKS peering mesh. It is not necessary for all server operators to do this, as long as enough people are doing so that an operator can always find a sufficiently recent dump to then use reconciliation to catch back up.

Key dumps can be used for restoring or allowing others to establish an SKS node and can be useful for various forms of off-line analysis. If your service continuity policies require you to be able to locally restore from backup, then you will need a keydump, but you should be able to get a current set of keys simply by reinstalling and letting the SKS peering mesh repopulate any changes since the dump you use for restore. All keys in SKS are considered public, there is no per-site key data.

There are three main approaches to creating a dump.

The problem

You can not dump a live serving SKS DB. The tool requires dedicated access to the storage

Approach: be offline

You can choose to just be off-line and unreachable for the duration of the dump process. This should probably be considered a last resort. If this is the only approach feasible for your setup, it's probably better to just not create dumps.

Approach: load-balanced server farm

You can run multiple SKS keyservers behind one public hostname, using your front-end HA proxy to distribute queries amongst the backends. This setup does risk that a newly uploaded change won't be visible from the same server again, and so peering with other servers should not be using the clustered hostname/IP.

Given such a setup, you can drop one server out of the serving pool, generate dumps, then restore the server to the serving pool.

Approach: filesystem snapshots

This approach involves a short outage, with the bulk of the time-consuming work being done while the server is running and serving real users.

In this, you use file-system level snapshot support; you quiesce the database so that no changes are being made, take a snapshot, then restore service and work with the snapshot.

1. shut down SKS
2. db_recover (both KDB and PTree)
3. db_archive (both KDB and PTree)
4. take filesystem snapshot
5. start up SKS
6. mount a read/write clone of the filesystem snapshot elsewhere
7. edit the sksconf in the mounted clone of the snapshot so that basedir, if present, points to this location
8. run sks dump from the snapshot
9. delete the snapshot

Strictly, the db_recover and db_archive are not needed for a snapshot if the snapshot can be mounted read-write, but they're a good sanity check nonetheless.

Use lsof and/or attempt to retrieve a key from your own keyserver to ensure that the dump is not still referencing the original databases and corrupting them. The most likely source of problems is if basedir is in the sksconf file: this will keep pushing the dump command back to the live data. If basedir is not present, then you probably do not need a read/write clone of the snapshot but should be able to just mount the snapshot read-only.