Backup & restore
Purpose: Know what must be backed up, the consistency requirements, and what restore actually looks like.
Who this page is for
| Audience | Why it matters to you |
|---|---|
| Platform engineers | Owners |
| Tech leads | RPO/RTO conversations |
What to back up
| Item | Why | Note |
|---|---|---|
| Author repository (crx-quickstart/repository) | THE content source of truth | Consistency required (see below) |
| Datastore (binaries) | Assets | Must be consistent WITH the node store — back up datastore first, then repo |
| Dispatcher/web configs, OSGi configs | Rebuild speed | Should already be in git |
| Package/artefact repo | Redeploy code | CI artefacts |
| Publish repos | Optional | Rebuildable from author (tree activation), but restore-from-backup is faster at scale |
Code needs no backup — git + CI artefacts are the recovery path. Content is the crown jewel.
Consistency
A running TarMK repo can be backed up online (the repo tolerates copy-while-append if done in the right order, or use the online backup mechanisms/filesystem snapshots). The rule that matters: datastore before segment store, so every binary reference in the repo exists in the binary backup. Filesystem/EBS snapshots of the whole volume are the pragmatic standard.
Restore realities
- Restoring author = restoring all content to a point in time — authors lose everything since. Communicate RPO honestly (daily backup = up to 24h authored work lost).
- Single-page recovery does NOT need backup restore: page versions (Timewarp/restore version) or a content package from the backup instance are surgical tools.
- Rehearse restores. An unrehearsed backup is a hypothesis, and the rehearsal doubles as your RTO measurement.
- After author restore: verify replication agents, re-sync publish (tree activation or publish restore), rebuild dispatcher caches (flush all).