Backups and restore
A backup is a zfs send stream taken from a snapshot, not a tarball of the
files. Ownership, extended attributes, ACLs, sparseness and recordsize all
survive, because none of them are being re-derived on the way out.
Status: local backups and restore are shipped and exercised. Remote targets can be configured and tested but do not upload yet.
What a backup run does
- Stop the application.
- Take a snapshot.
- Start the application again.
zfs sendfrom the snapshot, while the application is already running.
The application is down for the snapshot only: seconds, not the length of the transfer. The stream is checksummed and carries a self-describing manifest, so a backup can be identified without the database that produced it.
Restoring
Restore always receives into a fresh dataset and retains the previous one, so a restore that turns out to be wrong is a rollback rather than a loss.
A restore can also run under a new name and a new address, which puts a copy beside the original. That is the way to test a restore without touching the thing you are testing it against.
Browsing without restoring
Individual files can be browsed and extracted from a snapshot without a full restore. This is the common case for "I deleted one config file", and it does not need a spare dataset's worth of space.
Scheduling and retention
Jobs run on a schedule with per-kind retention. Retention also covers the datasets left behind by deletes and migrations, so a cluster does not silently fill up with orphans nobody is tracking.
Outline: the retention policy grammar, the interaction between a job's schedule and a manual run, and the verification pass all need writing up here.
Remote targets
S3-compatible targets can be defined and probed for real connectivity today. Uploading is the next major piece of work.