Veeam v13: Tape Integration, GFS Retention, and Compliance Architecture

Veeam v13 Series | Component: VBR v13 | Audience: Enterprise Architects, Compliance Teams, Hands-on Sysadmins

Tape isn't going anywhere. It shows up in almost every serious compliance requirement, every air gap conversation, and every long term retention discussion. The reason is simple: a cartridge physically removed from the library and stored offsite is genuinely air-gapped in a way that no networked storage can replicate. Object Lock is excellent. Tape in a vault is better for the longest retention tiers, because no software, no credential, and no API call can reach it.

This article covers the full tape workflow in Veeam v13: hardware setup, media pools and how they work, GFS retention explained properly with real schedule examples, offloading from disk to tape, restoring from tape, and where tape fits in a compliance architecture.

1. Tape Infrastructure Setup in Veeam

Adding a Tape Server

The tape server is the machine physically connected to your tape library or standalone tape drive. It's a separate role from the VBR server, though in smaller environments you can co-locate them. The tape server needs direct access to the tape device via FC, SAS, or SCSI. VBR communicates with the tape server over the standard Veeam management network.

1. In the VBR console, go to Backup Infrastructure, Tape Infrastructure, and right click Tape Servers. Select Add Tape Server.
2. Enter the hostname or IP of the server where the tape library is connected. VBR deploys the tape service components automatically.
3. After the tape server is added, VBR inventories the connected tape library automatically. You'll see the library appear under Tape Libraries in the Tape Infrastructure view.
4. Perform an initial inventory of the library. Right click the library and select Inventory. VBR reads the barcodes of all cartridges present and builds its catalog. This is required before you can assign tapes to media pools.

Media Pool Types

A media pool is a named collection of tapes with a defined policy for how data is written and how long it's kept. VBR has four types:

Creating a Standard Media Pool

1. Right click Media Pools in the Tape Infrastructure view and select Add Media Pool.
2. Name the pool clearly. Include the purpose in the name: for example, Daily-Backup-Pool or Archive-Monthly.
3. On the Tape tab, define how tapes are used: how much free space triggers moving to a new tape, whether VBR can append to existing media sets, and whether parallel writing is allowed (parallel writing uses multiple tape drives simultaneously for better throughput).
4. On the Retention tab, set the retention period. This is how long data on these tapes is protected from being overwritten. After the retention period expires, VBR moves the tapes back to the Free pool where they're available for reuse.
5. Assign physical tapes to the pool by right clicking specific tape cartridges in the library view and selecting Move to Pool.

2. GFS: What It Actually Means

GFS stands for Grandfather-Father-Son. It's a tape rotation scheme from the pre-digital era that defined how you physically managed backup tapes to give yourself multiple recovery windows at different granularities without needing an infinite number of tapes. Veeam's GFS tape job implements four named media sets:

• Weekly (Son): The last full backup of the week, typically Friday. Retained for 4 to 6 weeks. These tapes get reused after retention expires.
• Monthly (Father): The last full backup of the month. Retained for 12 months.
• Quarterly: The last full backup of the quarter. Retained for 1 to 3 years. Used in environments that need quarterly archives for financial or regulatory reasons.
• Yearly (Grandfather): The last full backup of the year. Retained for 5 to 7 years, sometimes indefinitely. These tapes go to long term vault storage.

The critical thing to understand about GFS in Veeam: the GFS tape job doesn't back up VMs directly. It copies from existing disk based restore points. Your regular VBR backup jobs write to disk repositories. The GFS tape job then copies from those disk restore points to tape according to the schedule. If the disk based backup for a given week, month, quarter, or year didn't run or failed, the GFS tape job has nothing to copy for that tier. GFS has four tiers only: weekly, monthly, quarterly, yearly. If you need daily copies to tape, use a separate standard Backup to Tape job pointed at the same disk repository.

3. GFS Retention with Real Schedule Examples

Example 1: Standard Compliance Schedule (7-year retention)

This is the schedule pattern you'd see in most regulated industries: healthcare, financial services, legal. It satisfies HIPAA, SOX, and most state data retention laws.

# GFS tape job tiers: weekly, monthly, quarterly, yearly
# For daily tape copies, run a separate standard Backup to Tape job

Media Set: Weekly (Son)
  Retention:    5 weeks (keep 5 Friday backups)
  Append:       Yes
  Overwrite:    After retention period expires
  Vault export: No
  Use case:     Recovery within the last month

Media Set: Monthly (Father)
  Retention:    13 months (keep 13 end-of-month backups)
  Append:       No (each month on its own tape set)
  Overwrite:    After retention period expires
  Vault export: Export after job completion
  Use case:     Month-end recovery, financial period recovery

Media Set: Quarterly
  Retention:    5 years (keep 20 quarterly backups)
  Append:       No
  Overwrite:    Never (WORM tapes recommended for this tier)
  Vault export: Export to offsite vault after job completion
  Use case:     Quarterly financial archives, regulatory examination backups

Media Set: Yearly (Grandfather)
  Retention:    7 years (keep 7 annual backups)
  Append:       No (each year on its own tape set)
  Overwrite:    Never (WORM tapes required for this tier)
  Vault export: Export to secure offsite vault, immovable for 7 years
  Use case:     Long-term legal hold, final audit archive

Example 2: MSP Standard Offering (3-year retention)

This is a practical schedule for MSPs offering managed backup with a tiered retention SLA.

# GFS tiers only: weekly, monthly, quarterly, yearly
# Daily tape copies: separate standard Backup to Tape job

Media Set: Weekly
  Retention:    4 weeks
  Use case:     "I need to recover that file from 3 weeks ago"

Media Set: Monthly
  Retention:    12 months
  Vault export: Monthly
  Use case:     End-of-year recovery, deleted user data recovery

Media Set: Yearly
  Retention:    3 years
  Vault export: Annual, sealed vault
  WORM tapes:   Yes
  Use case:     Contract expiry, compliance demonstration to customers

Configuring the GFS Tape Job

1. In the VBR console, go to Home, Jobs, and select Tape Job. Choose Backup to Tape.
2. On the Source step, select the disk based backup jobs whose restore points you want to copy to tape. You can add individual jobs or entire backup repositories.
3. On the Target step, select the GFS media pool you created. VBR automatically routes weekly, monthly, quarterly, and yearly copies to the correct media sets based on the schedule.
4. On the Schedule step, set the job to run daily. The GFS logic determines which media set a given run writes to based on the day of week, week of month, and month of year. You don't schedule each tier separately.
5. On the Full Backup step, configure which restore point type the job uses as its source. It can use the most recent restore point, or you can specify the full backup specifically to ensure tape content matches a known full disk state.

4. Offloading from Disk to Tape

Disk-to-tape offload is how you use tape as the capacity tier for older restore points that don't need to live on fast disk. VBR supports two approaches.

Backup to Tape Jobs (Explicit Copy)

A Backup to Tape job copies specific restore points from a disk repository to tape on a defined schedule. The disk copy remains intact. You end up with a disk copy and a tape copy. This is the right approach for compliance scenarios where you need to demonstrate that the tape copy exists as an independent backup, not just a reference to data on disk.

Archive to Tape from SOBR

If you're using a Scale Out Backup Repository, you can configure a tape archive tier. Restore points that age out of the performance tier (local disk) and would normally move to the capacity tier (object storage) can instead be written to tape. In the SOBR configuration, add the tape media pool as the archive tier. This is the most operationally efficient path for environments that already have SOBR configured and want tape as long term cold storage.

5. Restoring from Tape

Full VM Restore from Tape

1. In the VBR console, go to Home, Backups, Tape. You'll see tape based restore points listed alongside disk ones.
2. Right click the VM you want to restore and select Restore Entire VM. The restore wizard is the same as for disk based restores.
3. On the Restore Point step, select the tape based restore point. VBR will require the physical tape to be loaded in the library. If it's in offsite vault storage, you'll need to retrieve it before the restore can proceed. This is why tape is for the longer retention tiers: retrieval time is a real operational cost.
4. The restore streams data from tape directly to the target datastore. Throughput depends on the tape drive speed and the connection between the tape server and the restore target. LTO-9 drives sustain 400 MB/s native. Your network between the tape server and vSphere is typically the bottleneck.

File Level Restore from Tape

File level restore from tape uses the same Veeam file browser as standard file restores, but with an added step: VBR has to stage the backup file from tape to a temporary disk location before it can mount it and browse files. This staging step adds time, typically 20 to 60 minutes depending on tape position and file size. The staging location needs enough disk space to hold the full backup file being staged.

To set the staging location: in the VBR console, go to the Options menu for your tape server, and set the Tape staging folder path. A fast local disk or SSD is ideal here. Putting the staging folder on a slow NAS adds to the already significant restore time from tape.

Finding What's on a Tape

VBR maintains a catalog of tape contents in the VBR database. As long as the catalog is intact, you can browse what's on any tape without loading it into the library. If the catalog is lost or corrupted, you can rebuild it by running a catalog operation against physical tapes: right click the tape in the library and select Catalog. This reads the tape index and rebuilds VBR's record of what's on it.

6. Tape in a Compliance Architecture

WORM Tapes

WORM (Write Once Read Many) tapes are physically modified at the cartridge level so they can only be written once. After the initial write, the data can't be overwritten or erased regardless of what any software instructs. Even a Veeam operator with full administrator rights can't delete data from a WORM tape before the media's retention period expires.

VBR treats WORM and standard rewritable tapes differently. You can't mix them in the same media pool. If you try to add a WORM tape to a standard pool, VBR rejects it. Create dedicated WORM GFS media pools for the tiers where physical immutability is required (typically quarterly and yearly in most compliance frameworks).

WORM tapes cost more per cartridge than standard tapes (roughly 2 to 3 times more for LTO-9 WORM vs standard). For daily and weekly tiers that get reused frequently, standard tapes are the right economic choice. For yearly archive tapes that sit in a vault for 7 years, WORM is the right choice because the physical immutability guarantee is worth the cost.

The Air Gap Advantage

A tape cartridge physically removed from the library and placed in offsite vault storage is genuinely air-gapped. There's no network path to it. No ransomware can encrypt it. No credential compromise can delete it. No cloud provider outage can make it unavailable. The air gap is hardware enforced, not software enforced.

This is the argument for tape in modern environments that already have Object Lock on cloud storage. Object Lock is enforced by the cloud provider's software and APIs. It's strong. But if your cloud provider's control plane is compromised, or if a regulatory body issues a data hold that the provider must comply with, or if the provider's system has a critical bug, Object Lock can theoretically be overridden by entities with sufficient authority over the platform. A tape in a locked vault can't be affected by any of those scenarios.

Chain of Custody Documentation

Tape compliance programs need chain of custody documentation that answers: what data is on which tapes, when were they written, who has had physical access, where are they stored, and when are they scheduled for destruction. VBR provides the data side of this through its tape catalog and Veeam ONE's Tape GFS Configuration report. The physical custody side requires your organization's documented tape handling procedures and your vault provider's chain of custody receipts.

Auditors asking for proof of your long term retention compliance need four things: the tape catalog showing what data exists, the job run history showing when it was written, the vault provider's custody records showing where the tapes physically are, and the WORM tape manufacturer documentation confirming the physical immutability of the media type. VBR and Veeam ONE produce the first two. Your vault provider and tape vendor cover the other two.