Tape & offsite media

Tape remains the most economical medium for long-term retention, air-gapped copies and offsite vaulting. NGBackup inherits a battle-tested media-management core: tapes are just another kind of Volume, driven by the same Pools, retention rules and console you use for disk and cloud volumes.

Supported hardware

NGBackup supports standalone tape drives and multi-drive tape libraries / autochangers, from a single desktop LTO drive up to enterprise libraries with hundreds of slots. A library grows with you — add drives to the changer and declare one extra Device per drive (with its Drive Index) in the Autochanger resource; jobs spread across the drives automatically via Maximum Concurrent Jobs.

LTO compatibility

Generation	Native capacity	Native throughput
LTO-5	1.5 TB	140 MB/s
LTO-6	2.5 TB	160 MB/s
LTO-7	6 TB	300 MB/s
LTO-8	12 TB	360 MB/s
LTO-9	18 TB	400 MB/s

Barcode inventories, slot tracking, TapeAlert drive-health reporting (Alert Command) and WORM media detection (Worm Command) are all handled by the Storage Daemon — see the Device and Autochanger references.

Encryption on tape

Two independent layers are available; use either or both:

Hardware drive encryption (AES-256)

LTO drives from LTO-4 onward encrypt in silicon at full line speed. NGBackup‘s Storage Daemon manages the encryption keys and loads the per-volume key into the drive before writing, so cartridges leaving the building are unreadable without the key material held by the SD. Hardware encryption composes cleanly with drive compression (compress-then-encrypt) and adds no CPU load to the media server.

Software encryption (AES-128/256)

Data can also be encrypted with AES-128 or AES-256 before it ever leaves the client, using the File Daemon’s PKI encryption. This protects the data end-to-end — on the wire, on disk pools and on tape — independently of the drive hardware.

SAN support & LAN-free backup

Tape devices on a Storage Area Network can be shared among media servers running Windows, Linux and Unix. Each media server runs a Storage Daemon that addresses the shared drives through the SAN fabric, so backup and restore traffic flows LAN-free at fibre-channel/SAS speed instead of crossing the production network. Drive arbitration is coordinated by the Director: a shared drive is reserved for one job at a time, and multi-drive libraries let several media servers stream concurrently.

Dedicated backup network

To keep bulk backup traffic off the production LAN entirely, point clients at a secondary interface of the Storage Daemon — a Backup Area Network. Set FD Storage Address on the Client (or Storage) resource to the SD’s address on the dedicated segment; the control channel stays on the management network while the data channel uses the backup NIC:

Client {
  Name = "web01-fd"
  Address = 192.168.10.21             # management network (control)
  FD Storage Address = 10.99.0.5      # SD's interface on the backup network (data)
  ...
}

Disk-to-tape: Copy and Migration jobs

The recommended architecture is disk-to-disk-to-tape (D2D2T): back up to fast disk repositories first, then use Copy or Migration jobs to place a second copy on tape. Copy/Migration jobs are ordinary jobs — they are controlled by the same protection plans (schedules, pools, retention) and monitored from the same console and web interface as every other job; there is no separate tape tool to operate.

• Copy duplicates jobs from a disk pool to a tape pool, leaving the disk copy in place for fast restores. If the primary copy is later pruned, the tape copy is automatically promoted and used for restores.
• Migration moves jobs to tape and removes them from disk, freeing repository space.
• Selection types (PoolUncopiedJobs, PoolTime, Job, SQL query…) let you automatically copy the most recent backups to tape on whatever cadence your vaulting policy requires.

When the source is a deduplicated or incremental chain on disk, combine the copy with a VirtualFull so the data is rehydrated into a single self-contained full on the cartridge — the tape can be restored on its own, with no dependency on the disk repository or on other incremental volumes.

Example: library + daily copy-to-tape

# --- Storage Daemon ---
Autochanger {
  Name = "LibLTO9"
  Changer Device = /dev/sg3
  Changer Command = "/opt/backup/scripts/mtx-changer %c %o %S %a %d"
  Device = LTO9-Drive0, LTO9-Drive1
}

Device {
  Name = "LTO9-Drive0"
  Media Type = LTO-9
  Archive Device = /dev/nst0
  Control Device = /dev/sg1          # SCSI ctl for /dev/nst0 (TapeAlert)
  Alert Command = "/opt/backup/scripts/tapealert %l"
  Autochanger = yes
  Drive Index = 0
  AutomaticMount = yes
  Always Open = yes
  Removable Media = yes
  Random Access = no
  Maximum File Size = 8G
}

# --- Director ---
Pool {
  Name = "TapeVault"
  Pool Type = Backup
  Storage = "LibLTO9"
  Recycle = yes
  AutoPrune = yes
  Volume Retention = 5 years
}

Job {
  Name = "CopyToTape"
  Type = Copy
  Level = Full
  Selection Type = PoolUncopiedJobs   # copies the newest, not-yet-copied jobs
  Pool = "DiskPool"                   # source: disk repository
  Next Pool = "TapeVault"             # destination: tape
  Schedule = "NightlyAfterBackups"
  Priority = 12                       # runs after (higher-priority) backup jobs
  Maximum Errors = 5                  # abandon media after repeated write errors
  Messages = Standard
}

Synthetic full backups (VirtualFull)

A VirtualFull synthesizes a brand-new full backup from the last full plus subsequent incrementals/differentials without touching the client — the Storage Daemon reads existing volumes and writes a consolidated full. On tape this is doubly valuable: it rehydrates deduplicated and incremental data into a sequential, self-contained image, and it resets the restore chain so a DR restore needs exactly one set of cartridges. Run VirtualFulls to tape on your offsite cadence (for example, weekly) while daily incrementals stay on disk.

Restoring from tape

Restores from tape use the same restore workflow as any other medium:

• Individual files and folders — browse the catalog, mark items and restore them straight from the cartridge; there is no need to restore an entire image to extract one file. The catalog’s per-file positioning records let the drive space directly to the right tape file (see Maximum File Size on the Device resource).
• Full server image from tape to disk — for disaster recovery, restore the complete server (whole FileSet, or bare-metal image) from the tape set back to disk or to replacement hardware. A VirtualFull-synthesized tape means the whole restore comes from one self-contained set.

Offsite vaulting & media location

Every volume carries a location in the catalog, so the console always knows which cartridges are in the library, on the shelf, or at the vault:

* update volume=TAPE0042 location="Iron-Vault-SP" inchanger=no slot=0
* list volumes pool=TapeVault              # shows location, status, last written
* query                                    # canned queries include media-by-location

A typical vaulting cycle: run the copy-to-tape job, unmount/eject the cartridges, mark them with their vault location as above, and ship them. To recall media for a restore, bring the cartridges back, load them and resynchronize the catalog:

* update volume=TAPE0042 location="HQ-Library" slot=17 inchanger=yes
* update slots storage=LibLTO9             # barcode re-inventory of the magazine

Volume lifecycle, labeling and recycling are covered in Volumes, pools & auto-labeling.

Job control, error policies & pre-flight checks

• Priority — the Job Priority directive orders jobs on the shared drives: keep backups at a lower number (higher priority) than copy/vault jobs, so nightly backups always win the drives.
• Proactive error handling — Maximum Errors bounds how many I/O errors a job tolerates before failing the medium; failed jobs can be rerun automatically (Rerun Failed Levels, reschedule directives such as Reschedule On Error, Reschedule Interval, Reschedule Times), and TapeAlert diagnostics surface drive problems as job messages before they become data loss.
• Pre-flight test runs — the estimate console command performs a dry run of a job (estimate job=CopyToTape level=Full listing) and reports the exact file count and byte total before the job runs, so you can verify that enough tape capacity is loaded. Combined with the Messages resource, potential problems — not enough appendable media, drive alerts, mount requests — are notified by email or console ahead of and during the job.

NAS backup via NDMP

Network-attached storages that expose the NDMP protocol are backed up without installing an agent on the filer: the Storage Daemon receives the NDMP data stream from the NAS and writes it to tape (or disk) volumes, with the jobs scheduled, cataloged and restored through the same Director and console.

Backup levels on tape

Tape pools support the full range of levels — Full, Incremental and Differential — exactly as on disk. A common tape-only scheme is monthly Full + weekly Differential + daily Incremental to a rotating pool set; in a D2D2T design, dailies land on disk and tape receives periodic (Virtual)Fulls for vaulting. Separate pools per level (Pool, Full Backup Pool, Incremental Backup Pool, Differential Backup Pool on the Job) keep cartridge sets clean and recyclable on independent retention clocks.