Veeam File

The Veeam Backup & Replication connector imports backup run history into OverView for a consolidated view of your backup coverage and health.

Read-only. The script only uses Get-* cmdlets and read methods. It makes no changes, deletions, starts, or stops. It can be run safely in production.

Objective

The connector retrieves the following information, one row per machine per run:

• VM backup inventory (VMware / Hyper-V)
• Veeam Agent backups (physical machines, protection groups)
• Status, duration, and data volume per run
• Encryption and target repository
• SureBackup restore tests (optional)

Prerequisites

• Veeam Backup & Replication v12 or later recommended
• Veeam PowerShell module (Veeam.Backup.PowerShell) — built into the product, installed by default on the VBR server; on a remote machine, installed automatically with the VBR console
• PowerShell 5.1 on older VBR versions, 7.4.x on recent builds (if in doubt, use the PowerShell console built into Veeam via Console > PowerShell)
• Veeam Backup Administrator role — required by Veeam to run cmdlets
• Write access to the output folder (default C:\export\, created automatically if missing)

Procedure

Copy the script to the VBR server

Download or copy the script Export-VeeamBackupRuns.ps1 to your Veeam Backup & Replication server (or to any machine with the VBR console installed).

Loading…

Connect from a remote machine

If the script runs on a machine other than the VBR server, uncomment and update this line at the top of the script:

Connect-VBRServer -Server "VBR-SERVER-NAME-OR-IP"

Run the script

# Simple export, last 30 days (default)
.\Export-VeeamBackupRuns.ps1

# Shorter window + custom path
.\Export-VeeamBackupRuns.ps1 -LastDays 7 -OutputPath "D:\reports\veeam.json"

# Recommended first run (1 day, to gauge volume and duration)
.\Export-VeeamBackupRuns.ps1 -LastDays 1

# With backup type and restore tests
.\Export-VeeamBackupRuns.ps1 -LastDays 30 -IncludeBackupType -IncludeSureBackup

If the PowerShell execution policy blocks the script, allow it for the current session:

Set-ExecutionPolicy -Scope Process -ExecutionPolicy Bypass

Parameters

Exported fields

The schema is stable: all fields are always present. An unavailable field is null.

Sample output

[
  {
    "device_hostname": "SRV-APP01",
    "run_id": "a1b2c3d4-0000-0000-0000-000000000001",
    "parent_run_id": "f9e8d7c6-0000-0000-0000-0000000000aa",
    "run_name": "Backup Job Prod (Incremental)",
    "policy_name": "Backup Job Prod",
    "policy_type": "Backup",
    "started_at": "2026-06-28T22:00:13.0000000+02:00",
    "ended_at": "2026-06-28T22:14:51.0000000+02:00",
    "duration_seconds": 878,
    "status": "Success",
    "status_message": null,
    "read_size_mb": 40960.0,
    "transferred_size_mb": 5123.44,
    "run_backup_size_mb": 184320.0,
    "is_encrypted": true,
    "repository_name": "Repo-Principal",
    "storage_location": "E:\\Backups\\Repo-Principal",
    "backup_type": "Increment",
    "last_restore_test_date": "2026-06-25T03:10:00.0000000+02:00",
    "restore_test_status": "Success"
  }
]

Limits

• run_backup_size_mb is empty for machines backed up by Veeam Agent (Veeam does not write this statistic in their task session); for VMs, it is the size of the entire run (the same value on every row of the run) — do not sum it row by row. The run_ prefix signals this scope.
• Job-level fields (repository_name, is_encrypted) may be empty on agent backup rows: they are resolved from VM backup jobs. Machine-level data (name, timestamps, status, read/transferred sizes) remains populated.
• duration_seconds (and sometimes ended_at) can be null for a backup still running at export time: this is expected — the machine is covered, only the end time is not yet available.
• Veeam property names vary across versions. Each access is protected, so a moved property returns null, never an error. If a field is always empty, inspect the object on your version: Get-VBRBackupSession | Select-Object -First 1 | Get-Member.

Checklist after the first export (recommended with -LastDays 1):

• The JSON file is created and not empty
• The row count is consistent with the previous day's activity
• Physical machines (agent) appear
• status, timestamps, and durations match the Veeam console
• read_size_mb / transferred_size_mb are plausible
• repository_name matches the target repository on a VM row

# Upload a file to the veeam bucket
aws s3 cp veeam_backup_runs.json s3://veeam/veeam_backup_runs.json --profile ovs_your_org

# Or sync a whole local folder
aws s3 sync ./exports/ s3://veeam/ --profile ovs_your_org

import boto3

s3 = boto3.client(
    "s3",
    endpoint_url="https://s3.oversoc.com",
    region_name="fr-par",
    aws_access_key_id="YOUR_ACCESS_KEY",
    aws_secret_access_key="YOUR_SECRET_KEY",
)

# Push the export into the veeam bucket
s3.upload_file("veeam_backup_runs.json", "veeam", "veeam_backup_runs.json")