Skip to main content
Manage ISLE recovery bundles. Bundles contain the Drupal database and public/private files plus the Fcrepo database and object data when Fcrepo is enabled. Secrets are deliberately excluded and must be recovered from the organization’s Vault backup. Solr, Blazegraph, broker queues, caches, and derivatives are rebuildable state and are not included.

​
State boundary

Recovery bundles contain authoritative application state:
  • Drupal database
  • Drupal public and private files
  • Fcrepo database and object data when Fcrepo is enabled
They do not contain rebuildable Solr or Blazegraph indexes, ActiveMQ queues, IIIF caches, or generated derivatives. Customer secrets and source-controlled project configuration are deliberately excluded. Recreate the target from the matching site Git revision and template provenance lock, then recover secrets through the organization’s Vault backup before starting a restored site. The Fedora-enabled state of the target must match the bundle.

​
Back up and validate

Create a checksummed full-state recovery bundle
The command enters Drupal maintenance mode and pauses mutation-producing services while it captures consistent state. Move the resulting bundle to encrypted off-host storage with retention and scheduling that meet the customer’s documented recovery point objective (RPO). Validate the manifest, required artifact set, and SHA-256 checksums without changing the site: Validate a recovery bundle and display its state contract

​
Restore and recovery drill

Validate and restore an ISLE recovery bundle. This is destructive. The command briefly enters Drupal maintenance mode and pauses mutation consumers. After restoration, rebuild derived indexes and queues and run strict verification.
Restore is destructive and prompts before replacing authoritative state:
Run the restore first in a disposable context. Afterward:
  1. Rebuild Solr and Blazegraph indexes as applicable.
  2. Replay required derivative jobs and confirm queues drain.
  3. Run sitectl healthcheck.
  4. Run sitectl verify --strict.
  5. Confirm representative objects, binaries, IIIF delivery, and search.
  6. Record backup age as achieved RPO and elapsed recovery time as achieved recovery time objective (RTO).
Schedule this destructive recovery drill at least quarterly and after material topology changes. A successful checksum validation alone is not a restore proof.