Replication & tiered storage
Land fast on local disk, then replicate offsite to tape or the cloud.
- Land fast, replicate offsite
- Syncing
- Declaring recurring targets
- Replication and pruning are independent
Land fast, replicate offsite
The common operational shape is land fast, replicate offsite: dump to local disk (cheap, fast, online), then mirror the committed runs to tape or S3 for the offsite copy. NBackup has two commands for moving runs between media:
nb copycopies one run between media, choosing the endpoints with--from/--to(e.g. disk → tape).nb syncis the batch form ofnb copy: it copies every run the target medium is missing.
When the second copy should exist from day one, prefer a multi-landing route
over syncing: landing: [s3, gdrive] writes every new archive to both media from
local data, so nothing is downloaded from one cloud to feed the other (see
Storage media). nb sync then remains the tool for history — seeding
a newly added medium with the runs that predate it — and for repairing the gap a
failed landing left behind (nb sync --to gdrive).
nb sync works oldest first, so an interrupted sync makes contiguous,
replayable progress and a full always lands before its incrementals.
Syncing
nb sync --to lto --dry-run # preview: what disk has that tape doesn't
nb sync --to lto # copy the backlog
nb sync --to glacier --last 4 # only the 4 most recent runs
nb sync # run every rule in the config's sync: block
nb sync --from lto --to disk # un-vault: restage tape back to disk
The source defaults to the landing medium; --from overrides it, so the
same command both pushes offsite (disk → tape/S3) and pulls back (tape → disk).
Reading a tape source mounts the volume holding each run, just like a restore.
nb sync copies by default — pass --dry-run (-n) to preview without
writing. It is idempotent: each run copies atomically and records a second
placement, so re-running resumes where an interrupted sync left off, and a
fully-mirrored target reports “up to date”. On a hard error (target full or
offline) it stops and reports its progress.
Declaring recurring targets
Declare recurring replication in the config’s sync: block so a cron line is just
nb dump && nb sync:
sync:
- to: glacier # mirror everything to the object store
- to: lto
last: 4 # copy only the 4 most recent runs (does not remove older
# ones already on tape — `nb prune` trims)
- from: lto # second tier: tape -> deep-archive (source need not be landing)
to: deep-archive
nb sync with no --to runs every rule in the block; nb sync --to lto syncs a
single ad-hoc target.
Replication and pruning are independent
Replication and pruning are independent. Each medium prunes against its own retention, so a run leaves disk when disk’s capacity and cycle say so — never merely because a copy reached S3 or tape. Both copies are kept, each retained on its own terms.
To use a cheap offsite tier as bulk retention while disk stays lean, give disk a
tighter capacity (or a shorter minimum_age) than the tier: nb sync mirrors
runs offsite and nb prune independently trims disk back to its budget. A
restore reads from whichever copy is available.
See also: Pruning & retention, Storage media, Holding disk, and the disk → S3 scenario.