💾 ToastVault
Home · Blueprint

Section 3 Data Protection & Maintenance

Exam weight 26%

trapmemorisedefault valuetiplab Rate yourself: ○ not yet · ◐ shaky · ● know it (saved in this browser)

  1. 3.1 Backup files
  2. 3.2 Backup methods and their I/O cost
  3. 3.3 Retention and GFS
  4. 3.4 Backup copy jobs
  5. 3.5 Replication
  6. 3.6 Continuous Data Protection (CDP)
  7. 3.7 Application-aware and guest processing
  8. 3.8 NAS (unstructured data) backup
  9. 3.9 Physical workloads and enterprise plug-ins
  10. 3.10 Maintenance

Objective 3.1 Backup files

practice questions

On the official blueprint

• Backup jobs
• Backup copy jobs
• Replication jobs
• CDP
• Backup methods: forward, reverse, forever forward, synthetic full, active full
• Retention and GFS
• Application-aware processing
• Guest processing
• NAS backup
• Physical workloads
• Enterprise plug-ins: Oracle RMAN, SAP HANA, PostgreSQL, SQL Server
• Maintenance: health check, configuration backup, database maintenance, upgrade

3.1.1 Backup files

• .vbk · What it is: Full backup
• .vib · What it is: Forward incremental
• .vrb · What it is: Reverse incremental (rollback)
• .vbm · What it is: Backup metadata

VMware jobs use Changed Block Tracking (CBT), so an incremental reads only blocks that changed since the last run.

Official docs for 3.1 (1)

Objective 3.2 Backup methods and their I/O cost

5 cards practice questions

3.2.1 Backup methods and their I/O cost

• Forward incremental · How it works: Full, then increments. A new full (active or synthetic) starts a new chain. · I/O on the repository: 1 write per changed block
• Forever forward incremental · How it works: One full forever. When retention is exceeded, the oldest increment is merged into the full. · I/O on the repository: 1 write during backup, then 2 more during the merge (3 total)
• Reverse incremental · How it works: The .vbk is always the newest point. Old blocks are pushed out into .vrb files. · I/O on the repository: 3 per changed block (read + write + write)
• Synthetic full · How it works: Builds a new full from existing files on the repository. No production read. · I/O on the repository: 2 per block (read + write)
• Active full · How it works: Reads the whole VM from production again. · I/O on the repository: 1 write per block, but heavy load on production

MEMORISE

Reverse incremental = 3x I/O. Synthetic full = 2x I/O and no production load. Active full = full production read.

MEMORISE

Fast clone (ReFS on Windows, XFS on Linux) turns synthetic fulls and merges into metadata operations. They become fast and take almost no extra space.

TRAP

Only reverse incremental keeps the newest restore point as the full .vbk. A question saying “the latest point must always be a full file” points to reverse incremental.

Official docs for 3.2 (1)

Objective 3.3 Retention and GFS

2 cards practice questions

3.3.1 Retention and GFS

Short-term retention keeps restore points for a number of days or a number of restore points.

DEFAULT

Short-term retention for a new backup job is 7 days.

GFS (Grandfather-Father-Son) keeps selected full backups for long periods: weekly, monthly and yearly. GFS points are full backups flagged with a GFS tag and are kept outside short-term retention.

TRAP

GFS needs full backups to flag. Make sure the job produces a full (active or synthetic) for each GFS period, or there will be nothing to keep.

TRAP

On a hardened repository, a GFS full stays immutable for its whole GFS retention. A yearly full kept 7 years is immutable for 7 years.

Official docs for 3.3 (1)

Objective 3.4 Backup copy jobs

1 cards practice questions

3.4.1 Backup copy jobs

A backup copy job copies restore points from one repository to another. It reads from backup files, never from production. Use it for the offsite copy in 3-2-1.

• Immediate copy: copies each new restore point as soon as it appears.
• Periodic copy: copies the latest restore point on a schedule (for example, once a day).
• Supports its own retention and GFS, health checks, WAN acceleration and Cloud Connect targets.

TRAP

A backup copy job never reads from the production VM. If the source backup job stops, the copy job has nothing new to copy.

TRAP

You cannot switch an existing backup copy job between immediate and periodic mode. Create a new job in the other mode, then remove the old one. (Your practice bank asks this three times.)

MEMORISE

Only immediate copy mode copies SQL and Oracle transaction log backups.

MEMORISE

To move backups to a new repository, use Move backup. It is fast clone aware, so ReFS/XFS space savings survive. Copying files by hand (robocopy, rsync) re-inflates every cloned block and needs far more space.

Official docs for 3.4 (3)

Objective 3.5 Replication

2 cards practice questions

3.5.1 Replication

A replication job creates a replica VM on a target host, in a powered-off state. Each replica restore point is stored as a VM snapshot on the replica.

• Failover: power on the replica. Temporary until you decide what to do next.
• Undo failover: power the replica off and go back to production. Changes made on the replica are discarded.
• Permanent failover: the replica becomes the new production VM.
• Failback: sync changes back to the original (or a new) VM. Then commit failback or undo failback.
• Planned failover: for a known event. Does a final sync with the source VM off, so no data is lost.

Options: network mapping and re-IP for a DR site with different subnets, replica seeding (start from a backup instead of copying over the WAN) and replica mapping (use an existing VM at the target).

TIP

Check this against the current v13 docs. VMware replicas are limited by the snapshot chain to a maximum number of restore points (commonly quoted as 28). Confirm this in the v13 user guide.

Official docs for 3.5 (1)

Objective 3.6 Continuous Data Protection (CDP)

5 cards practice questions

3.6.1 Continuous Data Protection (CDP)

CDP replicates every write. No VM snapshots are used.

• Uses the VMware vSphere APIs for I/O filtering (VAIO). You install the Veeam I/O filter on the source and target clusters.
• Needs a CDP proxy at the source and target.
• Configured as a CDP policy, not a job.
• Short-term restore points: created every RPO interval. Crash-consistent.
• Long-term restore points: created on a longer schedule. Can be application-consistent.

MEMORISE

CDP RPO: minimum 2 seconds, Veeam recommends 15 seconds or more, maximum 60 minutes. The short-term journal keeps up to 168 hours (7 days).

DEFAULT

A new CDP policy has an RPO of 15 seconds and creates a long-term restore point every 8 hours.

NEW

Universal CDP: protects workloads such as physical servers into vSphere. It uses the Veeam CDP Agent Service and Veeam CDP Volume Filter Driver on the source machine.

Official docs for 3.6 (1)

Objective 3.7 Application-aware and guest processing

1 cards practice questions

3.7.1 Application-aware and guest processing

Application-aware processing (AAP) makes a backup application-consistent. On Windows it uses VSS so SQL Server, Exchange and Active Directory are quiesced cleanly. It can also truncate or back up transaction logs (SQL, Oracle).

Guest processing covers the in-guest actions: AAP, guest file indexing, and pre/post scripts.

• The guest interaction proxy deploys a runtime process (or uses a persistent agent) in the guest.
• If the guest has no network path, Veeam can use networkless communication through VMware Tools (VIX / vSphere Web Services) or PowerShell Direct on Hyper-V.
• SQL log backup: a log shipping server moves log backups to the repository. Allows point-in-time database restore.

TRAP

Without AAP the backup is only crash-consistent, like pulling the power plug.

TIP

Check this against the current v13 docs. SQL transaction log backups run every 15 minutes by default. Confirm in the v13 job settings.

Official docs for 3.7 (2)

Objective 3.8 NAS (unstructured data) backup

1 cards practice questions

3.8.1 NAS (unstructured data) backup

• Protects SMB and NFS shares, file servers, and (since v12) object storage buckets.
• Components: file proxy (reads the files), cache repository (holds metadata so later runs find changed files fast) and the target repository.
• Can read from a storage snapshot of the share so files are consistent.
• An optional archive repository keeps older file versions for longer.

TRAP

The cache repository stores metadata, not file data. Lose it and the next run must rescan the whole share, but no backup data is lost.

Official docs for 3.8 (1)

Objective 3.9 Physical workloads and enterprise plug-ins

1 cards practice questions

3.9.1 Physical workloads and enterprise plug-ins

Veeam Agents back up physical and cloud machines: Windows, Linux, Mac, AIX and Solaris. The backup server manages them through protection groups.

• Backup job (server-managed): for servers that are always on.
• Backup policy (agent-managed): for laptops and workstations. The agent runs the backup itself when it can.

Enterprise plug-ins let database admins keep their native tools while backups land in Veeam repositories:

• Oracle RMAN plug-in
• SAP HANA plug-in (Backint)
• PostgreSQL and SQL Server plug-ins

Official docs for 3.9 (1)

Objective 3.10 Maintenance

1 cards practice questions

3.10.1 Maintenance

• Health check (storage-level corruption guard): checks the latest restore point for corruption. If it finds bad blocks, the next job run fixes them by reading those blocks from production.
• Compact full backup file: rebuilds a long-lived .vbk to remove empty space. Used with forever forward and reverse incremental.
• Configuration backup: backs up the configuration database. Use it to restore or migrate the backup server.
• Database maintenance: runs automatically on the configuration database.
• Upgrade: take a configuration backup and stop running jobs first.

DEFAULT

The configuration backup job runs daily to the default backup repository.

TIP

Check this against the current v13 docs. Upgrade order commonly given: Veeam ONE first, then Enterprise Manager, then the backup server, then remote components. Confirm against the v13 upgrade checklist.

Official docs for 3.10 (1)