Backups
A backup job selects VMs, a Schedule, Retention and a Remote. A Remote holds independent recovery data; a run records one execution and a recovery point identifies a restorable VM state. Before scheduling backups, prepare reachable capacity in a separate failure domain and keep an hv engine running to execute queued work.
Configure a remote and job
Open System, Backups. Its sections include Jobs, Runs, Restore points, Remotes and Retention. Create a Remote, create the retention rule, then create a job with the intended VM selection and schedule.
The following example uses a prepared directory on the engine's machine, not the CLI workstation:
hv backup remote add backup-disk --kind local_dir --path /srv/hv-backups
hv backup retention set weekly --last 7
hv backup job create nightly --mode full --pool POOL --vm VM --remote backup-disk --retention weekly --schedule '0 2 * * *'
hv backup job show nightly
hv backup job run nightly
hv backup run list --job nightly
hv backup run show RUN_IDReview the VM selection and next run before leaving it scheduled. Schedules use five-field cron expressions in UTC. The CLI also configures NFS and S3 Remotes. For S3, supply the reference to the stored credential when configuring the Remote. Check access to the selected destination before assigning it to a scheduled job.
Choose a mode and retention
Full backups copy complete disk data. Delta backups use changed-block tracking and fall back to full data when that tracking resets. Rolling Snapshots keep points in the Pool without creating an independent disk copy. Continuous replication maintains a destination Replica; disaster recovery combines a Remote backup and replication. Mirror copies catalog points between Remotes. Metadata backups protect management state, not VM disks.
Retention must preserve dependencies of retained Delta points. Never delete individual parent VHDs to free space. Job deletion normally keeps recovery points; purge options deliberately remove them. Inspect dependencies before deleting a Remote.
Restore and test
Use Restore points to select the source and open the restore workflow. Choose the destination Project, Pool, SR and Network deliberately. For a test, use an isolated Network so the restored VM cannot conflict with the original.
hv backup points --remote REMOTE_ID --server https://hv.example.com:8443
hv backup restore POINT_ID --kind full --pool DESTINATION_POOL --sr DESTINATION_SR_UUID --network ISOLATED_NETWORK_UUID --name restore-test --server https://hv.example.com:8443
hv task show TASK_ID --server https://hv.example.com:8443Authenticate as described in CLI and API. Restore requires remote mode; SR and Network values here are UUIDs. The selected Network applies to every restored NIC. Wait for the Task, inspect the disks, boot the recovered VM in isolation and check application data.
File restore reads supported ext2/3/4 or NTFS contents into an archive; it does not overwrite the running VM. Unsupported filesystem features can be refused. Metadata recovery additionally needs the original deployment's protected key material and a coordinated restoration of database state; an A/B root rollback cannot perform it.
Back up and recover web-01
Suppose web-01 belongs to production and runs an application whose data must survive the loss of its Host. First decide how much recent work can be lost and how long recovery may take. Use those requirements to choose the schedule and retention; the example's nightly schedule and seven retained points are illustrative, not a guarantee that a week of application history is sufficient.
Prepare backup-disk on storage that remains available if the VM's Host fails. A directory on the same failed disk would not meet that objective even though a backup run could complete successfully. Confirm the engine can write there and that the destination has capacity for the selected mode. The CLI reference explains how to inspect the job and its runs.
Create nightly with web-01 as its selected VM, then inspect the saved job before running it. Check the Pool and VM identifiers rather than relying on the name alone. Run it once manually and wait for the run to finish. Review its diagnostic and verify that a recovery point appears before relying on the schedule. If the first run fails, correct that failure before adding more jobs.
For the recovery test, choose a point from that completed run and restore it as restore-test. Select a destination SR with sufficient space and an isolated Network. Do not attach the restored guest to the production Network while the original is active: the restored operating system may retain the original's address and service identity. The Network selected by the restore operation applies to all its NICs, so review guests with several interfaces particularly carefully.
After the restore Task succeeds, inspect the recovered VM's disk attachments and boot it in isolation. Sign in through its console and check application data from the chosen recovery time. A bootable operating system alone does not establish that the application can recover. Record which point was used, what data was checked and how long the recovery took. Remove the test VM only after confirming that it contains no data you need to keep.
Keep recovery usable
Review recovery points after changing VM selection, storage or retention. A job that no longer includes web-01 cannot protect its future changes. Similarly, metadata-only protection cannot replace the disk backup needed by this example. Keep management recovery material separate from ordinary support reports and available to the administrators responsible for a disaster recovery.
If a restore attempt fails after creating destination objects, inspect those objects before retrying. Decide whether they belong to the failed test or another workload, and retain the error details. Avoid deleting the backup point while diagnosing a restore failure; it may be the only independent copy available.
Common problems
A queued run needs a working engine, not another duplicate job. A transfer failure needs Remote connectivity, permissions and capacity checks. Inspect leftover destination objects after failed restores before retrying. A promoted Replica must be inspected before further replication because its protection prevents overwriting a possibly running recovery VM. A restore test checks whether the saved data can actually recover the service.