CHAPTER 20

Backup and Recovery

9 sections · 16 min read · SimpleVM 10.1

Backup and recovery planning protects virtual machines, host configuration, and business data from accidental deletion, a failed update, storage failure, ransomware, and site-level outages. A SimpleVM host should be included in the same production backup and disaster-recovery planning you apply to any other critical infrastructure. The goal is not only to produce backup files — it is to be sure the organization can restore service within an acceptable recovery window when something goes wrong.

This chapter works through the main decisions in order: what a backup plan must define, how to think about VM and host-configuration backups, how to scope storage-level protection, how to plan recovery before an outage, and how to prove that backups can actually be restored. It closes with the practices that make backup and recovery reliable under pressure. The chapter is deliberately product-neutral about backup software, because SimpleVM's supported backup tooling is still being confirmed; where a real install would supply a specific tool, destination, or command, that detail is tagged rather than assumed.

This chapter at a glance. The sections move from planning to proof:

• Plan the backup — define recovery objectives, retention, location, responsibility, and a testing schedule, and decide what to protect (Section 20.1).
• Protect the VMs — choose a backup approach and record what is needed to restore each workload (Section 20.2).
• Protect the host — capture the configuration needed to rebuild a SimpleVM host (Section 20.3).
• Scope the storage — identify the storage locations that backup jobs must include (Section 20.4).
• Plan the recovery — write the recovery path for each scenario before an outage forces it (Section 20.5).
• Test the backups — prove recoverability on a schedule, on an isolated network first (Section 20.6).
• Apply the practices — the habits that keep backup and recovery dependable (Section 20.7).

20.1 Backup Planning

Overview

A backup plan defines what must be protected, how often, where backups are stored, how long they are kept, and how recovery will be tested. For SimpleVM, that plan has to cover two distinct things: the virtual machines that run the workloads, and the host configuration needed to rebuild or recover the environment around them. Planning is required even for a single-host deployment — there is no second host to fall back on, which makes off-host backups more important, not less.

Backup planning goals

Settle these decisions before choosing any tool. They determine almost every later choice — how often jobs run, how much storage you need, and what “recovered” means for the business.

What to protect

A complete plan protects more than VM disks. Store the recovery notes themselves outside the protected VM, so the instructions survive the failure they describe.

20.2 VM Backup Considerations

Overview

A virtual-machine backup must protect enough to restore the workload — not merely copy one file. At a minimum that usually means the VM disk image and the VM definition. For application servers, databases, directory services, and other stateful workloads, application-aware or guest-level backup is often required as well, because a crash-consistent copy of a running disk may not be enough to bring the application back cleanly.

Common VM backup approaches

Using snapshots during backup preparation

A snapshot can preserve a point-in-time state before an update, a configuration change, or a short maintenance window, and some backup workflows use a snapshot as a stable source while the VM keeps running. Treat snapshots as temporary recovery points: long-running snapshots increase storage use and complicate disk-image management, and — as noted above — they generally share the VM's storage, so they are not a substitute for an off-host backup. Review snapshot state on the VM details view before a planned change.

Procedure: Record the information needed to restore a VM

Before you back up a VM, record what is required to restore it, so recovery does not depend on memory or undocumented assumptions.

1. Open the SimpleVM management interface and open Virtual machines.
2. Select the virtual machine you want to protect.
3. Record the VM name, guest operating system, CPU count, memory allocation, and firmware type.
4. Record each virtual disk, its network interfaces, and the virtual networks it attaches to.
5. Record the storage pool and disk image location for each VM disk (the VM details view shows this; see Figure 20-1).
6. Export or copy the VM definition if you intend to use command-line recovery. the SimpleVM-approved way to export a VM definition.
7. Store the recovery notes with the backup record — not only inside the VM being protected.

Verification

• The backup record identifies the VM by name and business purpose.
• Each VM disk is listed with its storage pool or path.
• The VM's network attachment is documented well enough to reconnect it during a restore.
• The recovery notes are stored somewhere reachable during an outage.

20.3 Host Configuration Backup Considerations

Overview

Host configuration backups let an administrator rebuild a SimpleVM host, compare current settings against a known-good baseline, and recover from a configuration mistake. This is not the same as a VM backup: it protects the settings that allow the host to run and manage VMs, rather than the workloads themselves. A host can be reinstalled from media, but its specific networking, storage, firewall, and virtualization configuration is what makes recovery fast instead of painful.

Capture at least the following, in whatever form your approved process supports:

• Network configuration — hostnames, IP addresses, DNS settings, bridges, routes, and interface roles.
• Storage configuration — storage pools, mount points, logical volumes, disk identifiers, and layout notes.
• Firewall configuration — allowed services, zones, and any custom rules that differ from the SimpleVM default.
• User and access information — administrative users, SSH access policy, and the support-access process.
• Virtualization configuration — VM definitions, storage-pool definitions, virtual-network definitions, and host-level virtualization service configuration.
• Operational notes — update history, maintenance windows, known exceptions, and recovery contacts.

Procedure: Create a basic host configuration backup record

1. Record the SimpleVM host name, management IP address, DNS servers, gateway, and time source.
2. Record the storage layout — the OS drive, the data drive, the storage pools, and any mounted backup destination.
3. Record virtual networks, bridges, DHCP ranges, and any static host entries.
4. Record the firewall zones and allowed services that differ from the SimpleVM default.
5. Export or copy the relevant host configuration files and VM definitions using the approved SimpleVM support procedure.
6. Store the backup record in a secure location outside the SimpleVM host.

20.4 Storage-Level Backup Strategies

Overview

Storage-level backups protect the storage location that holds VM disks and related data. They are useful when VM disks live on a dedicated data volume, on shared storage, or on a storage system that offers snapshot and replication features. The aim of this section is not to configure a specific array, but to be sure that backup scope follows where the data actually is — which on a SimpleVM host means the VM data location, not the operating-system drive.

Storage backup design questions

• Which storage pool contains the production VM disks?
• Are VM disks on local storage, shared storage, or external storage?
• Can the storage system create consistent snapshots?
• Can backups be copied to another server, a NAS, removable storage, cloud storage, or an off-site location?
• How will the backup be protected from accidental deletion or ransomware?
• How will storage be restored if the original SimpleVM host is unavailable?

Procedure: Identify storage that must be included in backup scope

1. Open the SimpleVM management interface and open the host Storage page.
2. Identify the operating-system storage and the storage location used for VM data.
3. Open Virtual machines and review the disk location for each production VM.
4. Open the Storage pools view and confirm which pools hold VM disks, ISO files, and supporting data (Chapter 12, Managing Storage Pools).
5. Document the storage pools and disk paths that backup jobs must include.
6. Confirm the backup destination has enough capacity for the chosen retention period (Section 12.7, Monitoring Storage Pool Capacity).

Verification

• Each production VM disk is mapped to a storage pool or storage path.
• Backup jobs include the VM data location, not only the SimpleVM operating-system drive.
• Backup destinations sit outside the primary storage failure domain where practical.
• Storage usage and retention growth are reviewed before the plan is relied upon.

20.5 Recovery Planning

Overview

A recovery plan explains how to restore service after data loss, VM failure, host failure, or a larger outage. A backup is only useful if the recovery process is known, documented, and tested. Recovery planning must precede the outage and cover scenarios from a single lost file through to a full site outage — and it must never assume that a restored copy is safe to start in production without checking for conflicts first.

Recovery scenarios to plan for

Procedure: Build a recovery checklist for a production VM

1. Identify the VM owner, business purpose, and acceptable downtime.
2. Record the backup source that should be used for recovery.
3. Record whether the VM should be restored in place, to an isolated test network, or to a replacement host.
4. Record the VM CPU, memory, disk, storage pool, and network requirements.
5. Record application-specific recovery steps — database consistency checks, service startup order, and similar.
6. Record the verification steps that prove the workload is healthy after the restore.
7. Store the checklist with the backup documentation.

20.6 Testing Backups

Overview

Backup testing confirms that backups can actually be used for recovery. A successful backup-job report does not prove that the VM, application, or host configuration can be restored — only a restore proves that. Test on a schedule and after any major change to storage, backup software, VM configuration, or host configuration.

Recommended test types

• Inventory test — confirm the expected VMs, disks, and configuration records exist in the backup set.
• File restore test — restore a file or folder from a guest-level or application backup.
• VM restore test — restore a non-production VM, or a clone of a production VM, into an isolated environment.
• Host rebuild test — confirm the host configuration records are enough to rebuild or reconfigure a SimpleVM host.
• Disaster-recovery exercise — walk the recovery plan through with the people responsible for the restore.

Procedure: Perform a controlled VM restore test

1. Select a VM that is safe to test, or use a non-production VM with similar storage and network requirements.
2. Confirm the backup set includes the VM disk and the information needed to recreate the VM configuration.
3. Restore the VM to an isolated test storage location or a test host.
4. Attach the restored VM to an isolated virtual network unless production access is required and approved.
5. Start the restored VM and confirm the guest operating system boots.
6. Confirm the expected applications or services start correctly.
7. Document the restore time, any issues found, and changes needed to improve the recovery process.
8. Remove the test restore once documentation is complete, unless it is being kept for further validation.

Verification

• The restored VM boots successfully.
• It has the expected disks, memory, CPU, and network attachment.
• The guest operating system can reach the expected data.
• Application or service checks pass.
• The restore process and total restore time are recorded.

Revert this change

A restore test deliberately creates temporary state on the host, so clean it up once the result is documented. Reverse only what the test introduced:

• Remove the test-restored VM and its temporary disk images after the result is recorded and approved.
• Disconnect and remove any isolated test virtual network created only for the test (Chapter 14, Managing Virtual Networks).
• Delete temporary copied files once they are confirmed no longer needed.
• Revert any firewall change opened only to allow backup or restore access (Chapter 16, Firewall and Security Settings).

20.7 Backup and Recovery Best Practices

Overview

These practices make SimpleVM backup and recovery more reliable, easier to audit, and easier to execute during an incident. None of them depends on a particular backup product; all of them survive a change of tooling.

• Separate OS and data storage. Use separate storage locations for the SimpleVM operating system and VM data where practical.
• Keep backups outside the failure domain. Never store the only backup on the same host or storage system as the running VM.
• Use multiple backup layers. Combine guest-level, VM-level, and storage-level backup where the workload requires it.
• Protect backup access. Limit who can delete, overwrite, or restore backups.
• Use immutable or offline copies where possible. Protect at least one copy from ransomware or accidental deletion.
• Document restore steps. Keep recovery steps with the backup set and in an accessible operations location.
• Test regularly. Test restores before an emergency forces the issue.
• Monitor backup results. Review failed, missed, or unusually small backup jobs.
• Retain application-aware backups for critical services. Databases, directory services, and transactional applications may need more than a crash-consistent VM image.
• Review after major changes. Update backup scope after adding disks, changing storage pools, changing networks, or moving workloads.

Revert this change

Backup planning itself does not change the SimpleVM host. Backup and restore procedures, however, can change VM state, storage usage, network attachment, firewall access, or host configuration depending on the method used. If a backup or restore workflow changes the environment, reverse only the specific change that was made — remove a temporary test restore, disconnect an isolated test network, delete temporary copied files once they are confirmed unneeded, or revert a firewall change opened only for backup access. Never reverse a change by deleting the recovery data it was protecting.

Troubleshooting

Advanced reference: VM disk backup commands

Some environments use command-line backup tools for VM disks. Red Hat Enterprise Linux documentation describes libvirt-based VM disk backup workflows using tools such as virsh backup-begin. Validate these against SimpleVM support guidance before publishing them as an official SimpleVM procedure.

Chapter review

After completing this chapter, an administrator should be able to define a backup plan in terms of RPO, RTO, retention, location, responsibility, and a testing schedule; decide what to protect across VM disks, VM definitions, host configuration, installation media, and recovery notes; choose an appropriate VM backup approach and record what is needed to restore each workload; scope storage-level protection to where VM data actually lives; write a recovery plan before an outage; and prove recoverability with a controlled restore test on an isolated network — understanding throughout that snapshots are temporary recovery points, not backups.