Skip to main content

​
Overview

In addition to the Polystack Native Backup for block storage volumes, the Polystack Platform is fully open to enterprise third-party backup solutions. Customers who need application-aware protection, long-term off-site retention, regulatory archive depths, or a single backup pane across multi-cloud and on-premises infrastructure can plug in the backup vendor of their choice. Third-party backup tools integrate with Polystack through OpenStack-compatible APIs and snapshot mechanisms — no proprietary backend changes are required.
Polystack Native Backup is the recommended starting point for most workloads. Adopt a third-party solution when you need capabilities Polystack Native Backup doesn’t cover — such as application-consistent quiescing for databases, indexed file-level recovery across thousands of guests, or cross-cluster / cross-cloud lifecycle policies.

​
Native vs Third-Party Backup

For most general-purpose workloads, the native backup is sufficient. Third-party tools shine when you have complex application stacks, multi-cluster fleets, or audit/archive requirements that need a dedicated backup product.

​
Two Integration Approaches

Third-party backup tools integrate with Polystack in one of two architectural patterns.

Agentless

The backup tool talks to OpenStack APIs (Block Storage, Image, Compute) and reads VM disks via snapshots. No software is installed inside the guest. Best for standardized fleets and snapshot-consistent backups.

With Agent

A small agent runs inside each guest VM. The backup tool coordinates with the agent to quiesce applications, capture file-level metadata, and stream changed data. Best for application-aware and granular file-level recovery.

​
Agentless Backup

Agentless backup uses OpenStack snapshot APIs to read VM disks. The backup tool calls the platform, asks for a snapshot, reads the snapshot’s data through standard storage APIs, and stores it in its own catalog.

​
How agentless backup works

Discovery

The backup tool authenticates with Polystack Identity and lists projects, instances, and volumes the backup user can see.

Snapshot

The tool calls Polystack Block Storage to take a snapshot of the target volume. The snapshot is crash-consistent (the same as a power-off + power-on).

Read snapshot

The tool streams the snapshot data through the storage API and stores it in its own backup repository (object storage, NAS, dedup appliance, tape, etc.).

Catalog and retain

The tool indexes the backup, applies the retention policy, and is ready to restore when needed.

​
Strengths of agentless

No guest footprint

Nothing runs inside the VM — no extra package to install, patch, or troubleshoot. Works for any guest OS, including hardened or appliance images.

Fleet-wide auto-discovery

The backup tool sees every VM through the OpenStack API. New VMs are picked up automatically by tag-based or project-based policies.

Lower operational overhead

No agent rollouts, no agent-version drift across the fleet. Upgrades happen on the backup-tool side only.

Snapshot-fast

Backup windows are short — the snapshot takes seconds, and reading happens asynchronously without locking the running VM.

​
Limitations of agentless

  • Crash-consistent only by default — a snapshot captures disk state without flushing application buffers. Databases may need replay on restore.
  • Limited application awareness — without an agent, the backup tool cannot quiesce Microsoft SQL, Oracle, Exchange, or similar transactional applications cleanly.
  • File-level restore needs extra work — the backup tool must mount and parse the guest filesystem to expose individual files (most agentless tools do support this).

​
Vendors that integrate with OpenStack APIs (agentless)

Recommended — Commvault has explicit, link-backed documentation for the four capabilities most commonly required of a third-party backup integration: deep VM-provisioning integration, rule-based auto-enrollment of newly created VMs, schedule + retention count, and on-demand backup. The full per-capability matrix is below the table.

​
Commvault capability matrix (with dedicated URLs)

Other strong agentless choices: Trilio and Storware also ship rule-based policy engines that pick up newly created VMs, but their public docs are slightly less explicit about “auto-enroll on VM create” enforcement. See their accordions below for the exact docs.

​
Schedule + retention reference docs (agentless)

Commvault — VM Group + Server Backup Plan (recommended)

Trilio’s protection model has two parts:
  • Workload Policies — admins define schedule + retention and assign policies to projects.
  • Workloads — group VMs to be backed up together with one of those policies.
Retention count — configured as the retention parameter on the policy (e.g. --hourly interval=1,retention=30,snapshot_type=incremental keeps 30 snapshots; default for hourly is 30, incremental). For one-off jobs the syntax is --manual retention=<count>,retention_days_to_keep=<days>.On-demand backup — yes. From the Workloads page in the dashboard, you can trigger a snapshot manually for any workload at any time, independent of the scheduled policy.For fully automatic discovery of newly created VMs, confirm the exact behavior in the current Trilio release notes — public docs describe policy-driven workload backup, not turnkey auto-enrollment of every new VM.
Storware’s SLA Policy combines schedule (daily / weekly / etc.) and retention in one policy. New VMs matching the policy’s project / tag selector are picked up on the next protection cycle. Full and incremental backups both supported.Retention count — configured per policy as a count of backups to keep, or as a time window. Storware moved retention from backup destination to the policy itself, so different policies can have different retention without changing the backup target.On-demand backup — yes. The Storware OpenStack plugin dashboard exposes a direct backup action per VM, independent of the SLA Policy schedule.
Veeam uses a job-level schedule combined with retention policies; GFS (Grandfather-Father-Son) schemes give you long-term tiered retention.
Cohesity Protection Policies define backup interval (minimum 12 h) and primary retention; Extended Retention adds longer hourly / daily / weekly / monthly / yearly snapshots beyond the primary policy.

​
With-Agent Backup

Agent-based backup runs a small piece of software inside each guest VM. The agent coordinates with the backup tool over the network to capture data with application-aware consistency and full file-level granularity.

​
How agent-based backup works

Install the agent

A backup agent package is installed inside the guest OS (Linux .deb / .rpm, Windows .msi). The agent registers with the backup server.

Quiesce the application

Before each backup, the agent calls application hooks (VSS on Windows, scripts on Linux) to flush database buffers, lock log writers, and ensure the on-disk state is consistent.

Stream changed data

The agent identifies changed blocks or files since the last backup and streams them to the backup server over the network.

Catalog with file-level index

The backup tool catalogs every file, registry key, or database object captured — enabling granular restore by name, not just full-volume restore.

​
Strengths of with-agent

Application-consistent backup

Microsoft SQL, Oracle, MySQL, PostgreSQL, Exchange, Active Directory, SAP, and other transactional apps are backed up cleanly with no replay needed at restore.

Granular file-level restore

Recover a single email, table row, registry key, or document from a backup — without restoring the whole volume.

Cross-platform consistency

The same backup tool protects VMs on Polystack, on-prem hypervisors, public clouds, and physical machines — one console, one policy framework.

In-guest encryption + dedup

Source-side deduplication and encryption reduce network traffic and protect backup data in transit and at rest.

​
Limitations of with-agent

  • Operational overhead — agent installation, version upgrades, and patching across the fleet require lifecycle management.
  • Guest OS coupling — agents are OS-specific (Linux distro, Windows version) and may not be available for some appliance images or hardened guests.
  • In-guest resource use — the agent consumes a small amount of guest CPU, memory, and network capacity during backup windows.
  • Doesn’t protect non-running VMs — if the VM is powered off, the agent isn’t running, so the backup tool falls back to agentless or snapshot mode.

​
Vendors that support agent-based backup on Polystack guests

​
Schedule + retention reference docs (with-agent)

Schedule + retention live on the NetBackup policy.
Schedule + retention are managed on the Server Backup Plan assigned to a VM Group.
Schedule and retention live in the Backup Plan together.
Bacula uses per-Job File/Job Retention and per-Pool Volume Retention.
Retention is defined in a Management Class within a Policy Domain.

​
Hybrid: Agentless + Agent

Many production environments use both approaches together:
  • Agentless for the bulk of the fleet — fast snapshot-based backups of stateless workloads, web tiers, and standard application servers.
  • With-agent for specific high-value VMs — databases, mail servers, ERP/SAP, domain controllers, and any workload where a few minutes of replay-on-restore is unacceptable.
A single backup tool typically supports both modes from the same console — pick the backup method per workload class via policy, not per-tool.

​
Choosing the Right Approach

Pick agentless. Snapshot-based backups are fast, fleet-wide, and good enough for stateless or session-replicated workloads.
Pick with-agent. Application-aware quiescing prevents database replay or corruption on restore. Trilio also offers app-aware workload types for databases via in-guest helper scripts.
Pick with-agent. VSS integration is essential. Veeam, Commvault, and Veritas all have strong Exchange and SQL Always-On support.
Pick agentless. You cannot install an agent into a sealed appliance image. Snapshot-based backup is the only viable option.
Pick whatever your audit framework prefers — most enterprise backup vendors offer immutable retention, write-once tiers, and audit reporting designed for these frameworks.
Pick agentless for the Polystack side and use the same vendor’s connectors for AWS / Azure / GCP / on-prem. Veeam, Commvault, Cohesity, Trilio, and Veritas all support multi-cloud.

​
How to Integrate a Third-Party Backup Tool

Provision a backup service account

Create a dedicated user in Polystack Identity with read access to all projects you want backed up. Grant the minimum roles required by the vendor (typically member plus volume:create_snapshot on Block Storage).

Allow OpenStack API access from the backup server

Ensure the backup tool can reach Polystack’s Identity, Compute, Block Storage, and Image API endpoints. Open required network paths, configure TLS trust, and (for agent-based mode) ensure guest VMs can reach the backup server on its data port.

Configure the vendor's Polystack connector

Each vendor ships an Polystack connector module. Point it at your Polystack Identity endpoint, supply the service account credentials, and select the projects to discover.
For Trilio, this is the Workload Manager Dashboard panel. For Veeam and Commvault, it’s a connector wizard inside the vendor console.

Define protection policies

Create backup policies — typically by tag, project, or VM list. Most vendors let you specify schedule, retention, target repository, and (for agent-based) application-quiesce settings.

Verify the first backup and restore

Run a test backup of a single VM, then perform a test restore to a new VM in a sandbox project. Confirm boot, network, and application functionality before enabling the policy fleet-wide.
The test VM restores successfully and applications start cleanly.
Always test restores on a regular cadence — quarterly at minimum. A backup you cannot restore is not a backup.

​
What Polystack Provides for Backup Vendors

Polystack exposes OpenStack-compatible cloud APIs that every modern backup vendor expects: For low-level integration, Polystack also exposes:
  • File-level read of snapshots through the File-Level Restore service — useful for backup tools that want to verify snapshot contents or build a file index.
  • Standard storage protocols — RBD for storage running on Software-Defined-Storage, NFS, iSCSI, and Fibre Channel for external arrays — so backup tools that prefer direct storage access can also integrate.

Polystack Native Backup

Volume backup with full + incremental modes — the built-in option

File-Level Restore

Recover individual files from a snapshot without a full restore