Traditional backup methods for QEMU/KVM virtual machines often force administrators to choose between two problematic approaches:

• Inconsistent snapshots that preserve uptime but risk data corruption
• Full shutdowns that guarantee consistency but create unacceptable downtime

The Linux Device Mapper subsystem provides the foundation for an elegant solution. Here's why it works:

# Basic device mapper snapshot creation
lvcreate -L 1G -s -n vm_snapshot /dev/vg0/vm_disk

Here's the complete workflow I've implemented in production environments:

#!/bin/bash
VM_NAME="production_vm"

# Step 1: Save state and pause VM
virsh save $VM_NAME /tmp/${VM_NAME}_state --running

# Step 2: Create device mapper snapshot
lvcreate -L 10G -s -n ${VM_NAME}_snap /dev/vg0/${VM_NAME}_disk

# Step 3: Restore VM
virsh restore /tmp/${VM_NAME}_state

# Step 4: Mount and backup snapshot
mkdir -p /mnt/${VM_NAME}_backup
mount /dev/vg0/${VM_NAME}_snap /mnt/${VM_NAME}_backup
rsync -avz /mnt/${VM_NAME}_backup/ /backup_storage/${VM_NAME}_$(date +%Y%m%d)

# Cleanup
umount /mnt/${VM_NAME}_backup
lvremove -f /dev/vg0/${VM_NAME}_snap
rm /tmp/${VM_NAME}_state

Key metrics from our production implementation:

For databases or other transactional systems, consider these enhancements:

# Flush database transactions before backup
virsh qemu-agent-command $VM_NAME '{"execute":"guest-exec", 
  "arguments":{"path":"/usr/bin/mysql", 
  "arg":["-e","FLUSH TABLES WITH READ LOCK"]}}'

While our solution works well, newer QEMU features offer alternatives:

• Active block commit (qemu 1.3+)
• NBD server export during backup
• Incremental backup support (qemu 4.0+)

Backing up running virtual machines presents unique technical challenges that traditional backup solutions often fail to address adequately. The primary issues boil down to two critical requirements:

• Data consistency: Ensuring the backup represents a valid system state without corruption
• Minimal downtime: Avoiding service interruption during the backup process

Most current approaches (as of 2013) suffer from significant limitations:

# Example of problematic snapshot approach
virsh snapshot-create --domain vm1 --disk-only --no-metadata

This creates an external snapshot but leaves you with management overhead and potential consistency issues.

Here's a detailed implementation of a reliable backup method using device mapper snapshots:

#!/bin/bash
VM_NAME="production-vm"
BACKUP_DIR="/backups/vms"
SNAPSHOT_SIZE="10G" # Adjust based on expected changes during backup

# Step 1: Save state and pause VM
virsh managedsave $VM_NAME

# Step 2: Create device mapper snapshots
for disk in $(virsh domblklist $VM_NAME | awk '/qcow2/ {print $2}'); do
    dmsetup create ${VM_NAME}-snap --table "0 $(blockdev --getsize64 $disk) snapshot $disk /dev/mapper/${VM_NAME}-cow p 64"
    dd if=/dev/zero of=/dev/mapper/${VM_NAME}-cow bs=1M count=$((SNAPSHOT_SIZE/1024/1024))
done

# Step 3: Resume VM
virsh start $VM_NAME

# Step 4: Backup from snapshots
for snap in /dev/mapper/${VM_NAME}-snap; do
    rsync -avz $snap $BACKUP_DIR/${VM_NAME}-$(date +%Y%m%d).img
done

# Step 5: Cleanup
dmsetup remove ${VM_NAME}-snap
rm /dev/mapper/${VM_NAME}-cow

The critical path for downtime consists of:

1. Saving VM state (typically <1s)
2. Creating device mapper snapshots (near-instantaneous)
3. Resuming VM (typically <1s)

Total downtime typically ranges from 1-3 seconds for most workloads.

For production environments, consider these enhancements:

# Use LVM thin provisioning for better snapshot management
lvcreate -V $SNAPSHOT_SIZE -T vg0/thinpool -n ${VM_NAME}-snap

# Include memory state in backup
virsh save $VM_NAME /tmp/${VM_NAME}.state

Always validate your backups:

qemu-img check $BACKUP_DIR/${VM_NAME}-*.img
virt-install --name test-restore --disk $BACKUP_DIR/${VM_NAME}-*.img --memory 2048 --noautoconsole

This approach provides atomic, consistent backups with minimal service interruption, solving the fundamental challenges of live VM backups.