Backup, Restore, Configuration Export, Blob Recovery, Disaster Scenarios, and Recovery Validation: Configuration, Design Choices, and Tradeoffs

1. Start from failure domains

Ask what you need to survive: accidental component deletion, cleanup-policy mistakes, database corruption, blob-store loss, host loss, region loss, secret loss, operator error, or a bad upgrade. Different failures require different evidence and restore points. A backup strategy that handles host loss may not handle malicious deletion if every backup is immediately mutable from the same compromised account.

2. Design matrix

3. Online versus offline: availability is part of the tradeoff

Online backup minimizes service interruption, but consistency across an embedded database and active blob writes can be harder to reason about. Offline maintenance windows reduce write concurrency and make the recovery point easier to describe, at the cost of planned downtime. For H2, Sonatype explicitly recommends regular offline embedded-database backups even though the H2 backup task exists.

For PostgreSQL, database-native online backup/PITR mechanisms can provide strong database consistency while Nexus remains online, but the operator still needs a coherent blob-store point and a procedure for reconciling bounded skew.

4. Backup frequency follows RPO, not habit

Suppose releases are published continuously and the business accepts at most 15 minutes of lost publication. A nightly database dump cannot satisfy the RPO. Conversely, a development proxy cache may tolerate a longer RPO because some content can be re-fetched. Classify repositories by business criticality instead of applying one schedule blindly.

recovery_classes:
  internal-releases:
    rpo_minutes: 15
    rto_minutes: 120
    criticality: high
  internal-snapshots:
    rpo_minutes: 240
    rto_minutes: 480
    criticality: medium
  public-proxy-cache:
    rpo_minutes: 1440
    rto_minutes: 480
    criticality: lower

5. Backup retention and repository retention are different controls

Cleanup policy may intentionally remove old components from the live repository. Backup retention determines how long older recovery points remain available. If cleanup immediately propagates to every backup copy, you have not created a useful rollback window. Define retention independently and protect recovery sets from accidental/malicious deletion through separate identities, immutable/WORM options where appropriate, and off-site/account separation.

6. Backups are a concentrated secret and IP boundary

Repository backups can contain proprietary binaries, internal coordinates, security configuration, credentials/tokens, certificate material, and metadata revealing software architecture. Apply encryption at rest/in transit, least-privilege backup identities, access logging, retention/destruction policy, and periodic restore access tests. Do not collect real secrets in a course evidence bundle.

7. Local file blobs versus object storage

File systems often make snapshots and offline copies easy to understand, but large datasets can make full copies slow. Object stores provide versioning, replication, lifecycle, and cross-region primitives, but those controls have provider-specific semantics. Record bucket/container versioning state, retention policy, encryption keys, replication lag, and restore process. “Replicated” is not the same as “backed up”: a mistaken deletion can replicate too.

8. When repository export/import is the right tool

Use Pro repository export/import for content migration, consolidation, or disconnected transfer when its supported format/behavior fits the requirement. Do not select it to recover users, roles, realms, repository definitions, server settings, or tags. Current import generates metadata/checksums and sets imported blob timestamps at import time, which is another reason it is not a byte-for-byte full-instance time-machine.

9. Backup, replication, and HA solve different problems

HA improves availability during some node failures. Replication maintains another copy with some lag. Backup preserves recoverable historical points. None automatically substitutes for the others. Chapter 28 handles HA/shared-state architecture in depth; this chapter’s rule is simpler: preserve independent recovery points even if the service is highly available.

10. RTO is often a throughput problem

Estimate restore duration before promising it:

size_tb = 8
usable_mib_s = 220
seconds = size_tb * 1024 * 1024 / usable_mib_s
print('hours:', round(seconds / 3600, 1))

This simplistic estimate ignores small-file overhead, object API request rate, database restore, verification, decompression, and contention. Measure actual restore drills and use the evidence to revise RTO.

11. Recovery ownership must cross team boundaries

Define who owns Nexus, PostgreSQL, storage snapshots, object-store policies, KMS keys, DNS/TLS, reverse proxy/load balancer, identity provider, and secrets. A runbook that says “DBA restores PostgreSQL” without an escalation contact, recovery point identifier, and validation handoff is incomplete.

12. Worked design scenario

A company has 4 TB of hosted internal releases, 10 TB of proxy cache, external PostgreSQL, and an RPO/RTO of 30 minutes/4 hours for releases. A sound design might:

• Use PostgreSQL PITR-capable backups with a declared recovery timestamp.
• Use storage snapshots/versioned object storage for hosted blobs aligned to the database point.
• Give proxy caches a looser backup objective or rebuild strategy, but preserve configuration/routing controls.
• Protect node ID/custom configuration and secret-recovery procedures.
• Perform quarterly isolated restores plus more frequent automated checksum sampling.
• Keep recovery credentials and delete permissions separated from normal Nexus administration.

The exact implementation depends on storage/database platforms and Sonatype support constraints, but the decision is driven by failure objectives and measurable restore time.

13. Knowledge check

14. Summary and bridge

Recovery design is a set of explicit tradeoffs among consistency, downtime, storage cost, security, and time-to-recover. H2 and PostgreSQL require different database procedures; file and object blobs require different storage controls; export/import solves content movement, not full DR. Lesson 4 now focuses on failures that expose bad assumptions and how to diagnose them without destroying remaining evidence.

Official references and version notes

• Sonatype: Backup and Restore — embedded H2 backup-task behavior and the role of database snapshots.
• Sonatype: Prepare a Backup — blob-store, node-ID, database, and custom-configuration backup requirements.
• Sonatype: Configure the Backup Task — current H2 task name and the recommendation for periodic offline embedded-database backups.
• Sonatype: Restore an H2 Database — stop/restore/restart sequence and same-point blob-store requirement.
• Sonatype: Nexus Repository Database — H2/PostgreSQL boundaries and PostgreSQL backup responsibilities.
• PostgreSQL: Backup and Restore — database-native backup methods for external PostgreSQL.
• Sonatype: Storage Guide — blob-store layout and the warning not to modify internal blob files manually.
• Sonatype: Data Repair Tasks — current plan-based reconciliation for database/blob inconsistencies and supported formats.
• Sonatype: Repository Export — Pro-only content export and its operational limits.
• Sonatype: Repository Import — Pro-only content import, generated metadata, and what is not preserved.
• Sonatype: Backup/Same-Site Restore — RPO/RTO and test-restore expectations.
• Sonatype: Resiliency — recovery expectations after database failure and the distinction from HA.
• Sonatype: Nexus Repository 3.95.x Release Notes — dated version line used as the chapter reference.