Chapter 16 · Backup, Restore, Transaction Logs, Disaster Recovery, and Upgrade Safety
Backup Encryption/Access, Offsite Copies, Retention Policies, and Immutable Recovery Evidence
Treat backup artifacts as sensitive production data: hash, protect, retain, copy off-host, test immutability controls, and preserve evidence that a specific artifact was actually restorable.
Learning outcomes
Classify backup artifacts as sensitive production data and control access accordingly.
Use hashes, metadata, object/version retention and append-only evidence to identify exact artifacts.
Design off-host/offsite copies that do not share the same failure/credential domain.
Choose retention from recovery/compliance needs instead of arbitrary “keep N” folklore.
Detect the false confidence created by same-host copies or untested immutability claims.
Reproducible AtlasMart setup
The continuity lab remains
Neo4j Community 2026.07.1, database
neo4j, explicit CYPHER 25 where
language behavior matters, container
atlasmart-neo4j, loopback Bolt
bolt://127.0.0.1:7687, synthetic credential
neo4j / atlasmart-course-2026, Java 21 or 25,
Python driver 6.3, and named volume
atlasmart-neo4j-data. Current 5.26 LTS is
5.26.30. APOC Core 2026.07.1 and GDS 2026.07.0 are
compatibility references only; neither is mandatory for this
chapter's Community drill.
Community provides offline
neo4j-admin database dump, load, and
consistency checking. Enterprise adds online full/differential
backup chains, backup metadata/aggregation, TLS-capable backup
service, and transaction-log replay during restore. The
self-managed neo4j-admin database backup command
is not an Aura workflow; Aura uses managed backup/recovery
features whose retention and restore controls depend on the
service tier. Do not claim that a replica, cluster member,
filesystem snapshot, or Aura copy is automatically equivalent
to a validated backup.
Every destructive command in this chapter targets disposable course containers/volumes or a new isolated restore volume. Never overwrite the only known-good store during a drill. Capture a hash and inventory first, restore to a separate target, validate it, and only then decide whether promotion is safe.
The drill adds one tiny course-owned marker so recovery correctness has a deterministic invariant even if your earlier AtlasMart graph has grown. The marker is not a substitute for business reconciliation; it is a canary.
CYPHER 25
CREATE CONSTRAINT recovery_marker_id IF NOT EXISTS
FOR (m:RecoveryMarker) REQUIRE m.markerId IS UNIQUE;
MERGE (c:Customer {customerId:'C-1001'})
ON CREATE SET c.name = 'Mina Rahimi'
MERGE (m:RecoveryMarker {markerId:'DR-CH16-001'})
SET m.createdAt = datetime('2026-09-09T17:00:00Z'),
m.expectedState = 'before-dump',
m.exercise = 'chapter-16'
MERGE (c)-[:HAS_RECOVERY_MARKER]->(m);
MATCH (m:RecoveryMarker {markerId:'DR-CH16-001'})
RETURN m.markerId, m.expectedState;
| Assumption | Pinned value / rule |
|---|---|
| server | Neo4j Community 2026.07.1; 5.26.30 is the current LTS comparison line |
| Java | 21 or 25 for current 2026.07 server |
| database / volume | neo4j / atlasmart-neo4j-data |
| transport | loopback Bolt without TLS only for this disposable local lab |
| backup destination |
new host directory ./neo4j-dr/backups;
production must be off-host and access-controlled
|
| plugins | none required; if installed, inventory exact APOC/GDS versions before upgrade/restore |
| measurement | record real start/end timestamps and artifact hashes; no invented RPO/RTO numbers |
1. A backup can be a data-exfiltration package
A Neo4j dump contains graph data outside the normal database authorization path. If an attacker can read the artifact, database RBAC no longer protects those bytes. Protect backup directories/object stores with filesystem/cloud IAM, encryption at rest where your platform provides it, restricted keys, audit logs and deletion controls.
| Asset | Threat | Control evidence |
|---|---|---|
| dump/full backup | unauthorized read/exfiltration | least-privilege storage ACL/IAM + encryption + access log |
| backup chain | missing/altered differential | hash/metadata/chain coverage + restore validation |
| encryption key | loss or compromise | separate key lifecycle, rotation/recovery owner |
| runbook | credential leakage | placeholders/secret references, not plaintext production secrets |
| restore host | malicious/old plugin | clean image + pinned server/plugins + isolated network |
2. Create an evidence manifest
Hashing does not encrypt or prove semantic correctness; it binds your later test to the exact bytes you intended. Record artifact size/hash, server version, database, creation time and storage location in a separate control plane.
mkdir -p ./neo4j-dr/evidence
sha256sum ./neo4j-dr/backups/neo4j.dump | tee ./neo4j-dr/evidence/neo4j.dump.sha256
stat -c '%n %s bytes %y' ./neo4j-dr/backups/neo4j.dump | tee ./neo4j-dr/evidence/neo4j.dump.stat
printf 'server=2026.07.1\ndatabase=neo4j\nexercise=chapter-16\n' \
> ./neo4j-dr/evidence/manifest.txt
A matching SHA-256 detects byte changes relative to the recorded digest. It does not prove who created the artifact, that the digest itself is trustworthy, or that the artifact contains the intended business recovery point.
3. Off-host/offsite means a different failure domain
Copying neo4j.dump from /data to
another directory on the same disk is not meaningful disaster
isolation. At minimum separate the storage failure domain; for
stronger resilience, separate host/site/account credentials and
use retention/object-lock mechanisms appropriate to your
platform.
| Copy pattern | Failure independence |
|---|---|
| same directory/disk | almost none |
| different disk, same host/admin | disk failure improved; host/admin compromise shared |
| different host, same identity domain | host loss improved; credential compromise may still be shared |
| separate account/site + restricted immutable retention | stronger protection against local/admin/ransomware classes; still requires restore tests |
4. Retention is a policy, not a number copied from a blog
Retention must satisfy the longest realistic detection window, legal/compliance requirements, rollback/migration needs, and the desired set of recovery points. Cost includes storage, object-lock minimums, egress, consistency tests and operator time.
| Question | Why it changes retention |
|---|---|
| How late can corruption be detected? | you need a recovery point older than detection delay |
| How frequently does data change? | drives RPO and differential volume |
| Which backups anchor upgrade rollback? | pre-change artifacts may need longer retention than daily operational copies |
| Can external systems replay missing events? | may permit larger graph RPO if reconciliation is proven |
| What legal deletion duties apply? | backups may need controlled expiration, not indefinite retention |
5. Immutable evidence vs “read-only” theater
A local chmod -w is useful against accidents but an
administrator can undo it. True immutability depends on a
control outside the same compromised identity path—for example
object-lock/WORM retention administered separately. The course
lab uses a deterministic simulation: make a second copy, remove
write bits, verify accidental write failure, and explicitly
label that as not equivalent to cloud/object-lock
immutability.
mkdir -p ./neo4j-dr/immutable-sim
cp ./neo4j-dr/backups/neo4j.dump ./neo4j-dr/immutable-sim/neo4j.dump
chmod a-w ./neo4j-dr/immutable-sim/neo4j.dump
sha256sum ./neo4j-dr/immutable-sim/neo4j.dump
# Administrative/root identities may still override local file permissions.
6. Enterprise backup-chain evidence
An online backup artifact includes metadata such as database identity, time and transaction-ID coverage. Model the chain as a dependency graph: a full artifact is the store anchor and differential artifacts provide transaction ranges. A missing required parent/interval can invalidate the intended recovery point.
| Artifact | Synthetic coverage for reasoning | Valid? |
|---|---|---|
| FULL-F0 | tx 100–200 | anchor |
| DIFF-D1 | tx 201–230 | contiguous child |
| DIFF-D2 | tx 231–250 | contiguous child |
| DIFF-D3 without D2 | tx 251–280 | not enough to restore through 280 if D2 is unavailable |
Starting with 2026.02, the first differential may overlap the preceding full. That scheduling flexibility does not remove the need for a recoverable chain and validated metadata.
7. Evidence checklist
| Control | Evidence retained |
|---|---|
| confidentiality | storage ACL/IAM review, encryption/key owner, restore-host isolation |
| integrity | hashes + metadata + consistency/restore result |
| availability | off-host/offsite copies and retrieval test |
| immutability | platform retention/object-lock state or explicit statement that local simulation is weaker |
| recoverability | dated restore drill with business/application verification |
| expiry | retention/deletion schedule and legal/compliance owner |
Check your understanding
- Does hashing encrypt a dump?
- Is a second directory on the same disk an offsite backup?
- Why retain a pre-upgrade artifact longer?
- Is local read-only permission true immutability against an administrator?
- What makes chain evidence useful?
Review the answers
1. No. Hashing is integrity/identity evidence, not confidentiality.
2. No. It shares the same disk/host failure domain.
3. It may be the only clean rollback point compatible with the old server/store/plugin stack.
4. No; it is only an educational accident-prevention simulation.
5. It ties exact artifacts to recoverable transaction coverage and later restore results.
Production judgment
| Review area | Decision evidence |
|---|---|
| graph/workload fit | recovery scope includes every database and external dependency needed to make AtlasMart useful, not only graph files |
| correctness | restored node/relationship/business invariants and application smoke tests; a successful command exit is insufficient |
| RPO/RTO | measured from real cadence, last recoverable point, restore duration and operator/application recovery steps |
| transactions/concurrency | backup method preserves a consistent recoverable state; log retention covers required differential/PITR window |
| memory/CPU/disk/network | backup, restore and consistency-check resource use measured separately from normal workload |
| indexes/constraints | index/constraint state reconciled after restore; rebuild/population time included in RTO if applicable |
| driver/service | pool/retry/bookmark behavior revalidated after endpoint/version changes; ambiguous writes reconciled |
| security | backup files encrypted/protected by platform controls, least-privilege access, secret/certificate handling and deletion policy |
| observability | backup age, artifact chain, failures, restore drills, disk pressure and operator actions are monitored/audited |
| version/edition | server, store format, Java, Cypher, driver, APOC/GDS and Aura/self-managed boundaries captured before change |
| rollback | pre-upgrade artifact remains immutable and compatible with the rollback server; rollback trigger and owner are explicit |
| cost/governance | retention, egress/object-lock/license cost balanced against business RPO/RTO and compliance requirements |
Summary and next step
Protected, identified and tested artifacts give disaster recovery a trustworthy input. Lesson 4 uses that rollback anchor to plan a Neo4j server/store/plugin/Cypher upgrade without assuming backward compatibility.
Authoritative references
- Current Neo4j versions — Current server and 5.26 LTS release snapshot.
- Backup and restore — Edition-aware entry point for dump/load, online backup, restore and planning.
- Backup and restore planning — RPO/RTO, backup mode, storage location, cadence and retention planning.
- Back up an offline database — neo4j-admin database dump semantics and Community offline boundary.
- Restore a database dump — neo4j-admin database load semantics, overwrite rules and edition differences.
- Back up an online database — Enterprise full/differential backup artifacts and chain semantics.
- Restore a database backup — Enterprise recovery of backup chains and restore-until predicates.
- Check database consistency — neo4j-admin database check for stores, dumps and recovered full backups.
- Transaction logging — Transaction-log retention, checkpointing and pruning behavior.
- Store formats — Current aligned/block formats, limits and legacy-format deprecation.
- Migrate a database — neo4j-admin database migrate and store-format migration boundaries.
- System requirements — Supported Java/runtime and platform requirements for current Neo4j.
- APOC installation — APOC/server release compatibility and restart/deployment coupling.
- GDS compatibility — Graph Data Science and Neo4j version compatibility matrix.
- Python driver installation — Current 6.x driver/server compatibility baseline.