Recovery methodsTechnical

Live Systems, Snapshots and Consistent Recovery Copies

A sector copy can be complete and still fail to represent one coherent moment in time. Databases, virtual machines and active file systems may change while they are being copied, so recovery from a live system has both an acquisition problem and a consistency problem.

Readable is not the same as consistent

If metadata is copied before a transaction and related data blocks after it, the resulting image can contain states that never existed together on the source. Ordinary desktop files may tolerate this; databases, VM disks and storage metadata can be much more sensitive.

Quiescing reduces change during acquisition

Stopping an application, unmounting a file system or otherwise quiescing writes can create a more stable source state. Whether that is practical depends on the system and on the risk of shutting it down.

Snapshots can provide a point-in-time view

A suitable snapshot can expose a logically stable view while the original system continues operating. But a snapshot is not automatically an independent backup: many snapshots depend on the same underlying storage and can disappear with the pool, device or metadata they rely on.

Application-aware consistency goes further

For transactional applications, a storage-level snapshot may be crash-consistent rather than application-consistent. Database logs, VM integration mechanisms and application-specific backup procedures may be needed to obtain a state that the application can recover cleanly.

Recovery may still use an inconsistent copy

An imperfect live copy can remain valuable, especially when it is the safest available acquisition. The important part is knowing how it was created so later reconstruction can account for possible in-flight changes.

Two questions, not one

Ask both “Did we copy the readable blocks?” and “Do those blocks represent a coherent point in time?” They are separate properties.