Take a VM Snapshot and Register It as an Asset

Backups you cannot enumerate are backups you cannot trust. This blueprint takes a snapshot of an existing virtual machine and registers it as a typed io.kestra.plugin.ee.assets.VM.Snapshot asset in the Kestra asset catalog, recording the retention policy, the trigger that caused the backup, and the machine it protects. The VM is declared as an input asset, so every snapshot is linked to its source machine in the lineage graph, and questions like "when was this box last backed up" become catalog queries.

How it works

1. The target_vm input names an existing VM (default windows-web-01).
2. The gcp_snapshot task simulates the backup with io.kestra.plugin.core.log.Log, printing the conventional backup name backup-{{ inputs.target_vm }}-{{ execution.startDate }}. In production you replace it with a real task, for example io.kestra.plugin.gcp.cli.GCloudCLI running gcloud compute disks snapshot.
3. The task declares the VM as an assets.inputs entry using its slugified id, creating the lineage edge from machine to backup.
4. It registers the snapshot as an assets.outputs entry of type io.kestra.plugin.ee.assets.VM.Snapshot, keyed by a slugified combination of VM name and execution id, with metadata for retention, trigger, and vm.

What you get

• A cataloged VM.Snapshot asset per backup, with retention and provenance metadata.
• Lineage from VM to snapshots, so restore planning starts from the asset graph.
• A queryable backup inventory: assets(type='io.kestra.plugin.ee.assets.VM.Snapshot') lists every registered snapshot, filterable by metadata.vm.
• The raw material for retention enforcement, since retention metadata plus asset age drives purge decisions.

Who it's for

• Infrastructure and SRE teams who must prove backup coverage per machine.
• IT operations teams enforcing retention policies across snapshot sprawl.
• Platform engineers building an asset-driven suite where backups are governed like any other resource.

Why orchestrate this with Kestra

Cloud snapshot APIs create backups but scatter the evidence across consoles and regions. Kestra registers the snapshot in a central catalog in the same task that creates it, so coverage reporting never depends on scraping provider APIs later. Schedules turn this into an automated backup policy, retries absorb transient API failures, and execution history documents every backup ever taken, including the ones that failed.

Prerequisites

• A Kestra Enterprise Edition instance (Assets are an EE feature).
• A VM asset already registered, for example by the asset-create-vm blueprint, matching the slugified target_vm value.

Secrets

• None required by the stub. Add cloud credentials as secrets when you wire in a real snapshot task.

Quick start

1. Run asset-create-vm so the target VM exists in the catalog.
2. Import this blueprint and execute it with the same target_vm.
3. Open the Assets view to see the VM.Snapshot asset with retention metadata and lineage.
4. Add a Schedule trigger to turn it into a nightly backup policy and set trigger metadata accordingly.

How to extend

• Replace the Log stub with io.kestra.plugin.gcp.cli.GCloudCLI or io.kestra.plugin.aws.cli.AwsCLI to take a real disk snapshot.
• Add an io.kestra.plugin.core.trigger.Schedule trigger for recurring backups and stamp trigger: scheduled-backup in metadata.
• Build a companion purge flow that removes snapshot assets older than their retention window.
• Notify a channel on completion with the snapshot asset id for one-click restore lookups.

Links

• Kestra Assets documentation: https://kestra.io/docs/enterprise/governance/assets
• Core plugin docs: https://kestra.io/plugins/core