Use snapshots for controlled change points

A safety checkpoint, not a complete backup plan

A snapshot records server or disk state at a point in time. It can be useful before a package upgrade, configuration change, or application release because it creates a known reference to return to if the change fails. Snapshot consistency depends on what applications were doing when the capture occurred.

HostGanga snapshot support, limits, retention, and restore behaviour depend on the server platform and plan. Confirm current availability before building an operating procedure around it, and keep independent backups outside the failure domain of the live server.

Change checkpoints

Capture a known state before maintenance that could alter operating-system or application files.

Documented rollback

Pair each snapshot with the change ticket, creation time, owner, and a clear expiry date.

Application awareness

Quiesce databases or use application-native procedures when crash-consistent disk state is not sufficient.

When snapshots are useful

Snapshots fit planned, short-lived risk: major updates, control-panel changes, migrations, or testing a configuration. They should be created deliberately and removed when no longer needed rather than allowed to become an undocumented retention system.

• Before operating-system updates
• Before application releases
• At a defined migration checkpoint

Protect data beyond the snapshot

A snapshot may share infrastructure, credentials, or account access with the source server. That means deletion, platform failure, or account compromise can affect both. Send backups to a separate destination, define retention, and periodically restore a sample. Database-native backups may still be needed for transactional consistency.

Frequently asked questions