Snapshots and custom images in the cloud

Why Is a Snapshot Essential Before High-Risk Changes?

Anyone who has worked with a cloud server has experienced the bitter moment of a service failure at least once. A bad update, a wrong change in Nginx configuration, or a rm -rf command that targeted the wrong path — and suddenly your site is down and users are seeing error messages. In such moments, the only thing that can save you is a fresh and healthy snapshot.

A cloud snapshot is an instant image of your server's disk state at a specific moment. This image includes files, configurations, databases, and everything written on the disk. The main difference between a snapshot and a regular backup lies in speed and recovery method: you can attach a snapshot to a new disk or boot a server from it within minutes, without needing to reinstall the operating system or restore files.

In this article, you will learn how to take a snapshot before any high-risk change, manage it, and quickly roll back to the previous state if something goes wrong. All commands and examples are practical and can be executed on your server right away.

When Should You Take a Snapshot?

The golden rule is: before any change that, if it breaks, you cannot easily revert. Specifically, consider these scenarios:

• Linux kernel upgrades or major security updates (such as apt upgrade or yum update)
• Changing the version of PHP, MySQL, or Nginx
• Running database migrations in Laravel or Django projects
• Changing firewall or network settings that might cut off SSH access
• Installing a new control panel or a critical plugin
• Changing partition structure or increasing disk size

Important note: a snapshot is not a replacement for regular backups. Snapshots are for quickly returning to a specific point, while periodic backups (e.g., daily) are essential for protecting against hardware failure or accidental data deletion. Have both.

Difference Between Snapshot and Custom Image

Many people confuse these two concepts. A snapshot is an instant image of the disk, usually used for quick recovery, and can also serve as a base for creating a new server. However, a custom image is a ready-made template that includes the operating system, base configurations, installed software, and your settings, from which you can create multiple new servers with the same state.

In simple terms: a snapshot is for "going back to the past," while a custom image is for "repeating a good state in the future." If you have an excellent configuration you want to use for future projects, create a custom image from it. If you just want security before a high-risk change, a snapshot is sufficient.

Taking a Snapshot in Practice

The method of taking a snapshot depends on your infrastructure. If you use the ServerNet control panel, there is usually a "Take Snapshot" button in the disk or server management section. But if you work with APIs or the command line, you should know what happens behind the scenes.

Preparing the Server Before a Snapshot

A good snapshot is one that stores the disk state in a consistent manner. If files are being written at the moment the snapshot is taken, your snapshot might be corrupted. To avoid this problem:

1. Flush the database: mysql -u root -p -e "FLUSH TABLES WITH READ LOCK;" (and after the snapshot, run UNLOCK TABLES;)
2. Sync the filesystem: sync
3. If you use LVM, use an LVM snapshot, which ensures consistency on its own.

In most cloud panels, snapshots are automatically taken at the block level, and these steps are not needed. But if you want peace of mind, run these three commands before taking a snapshot.

Practical Example with OpenStack API

If your server runs on OpenStack (which many cloud providers, including those based on it, use), you can take a snapshot with the following command:

openstack server image create --name "snapshot-before-update-$(date +%Y%m%d)" --wait my-server

This command creates a snapshot with a date-based name that you can identify later. To restore, simply create a new server from this snapshot:

openstack server create --flavor my-flavor --image "snapshot-before-update-20250601" --network my-network restored-server

If you use ServerNet's own API, check its documentation — there is usually an endpoint for creating snapshots that you can call with curl.

Quick Restore from a Snapshot

The most important feature of a snapshot is the speed of restoration. When something bad happens, follow these steps:

Step 1: Diagnose and Cut Off Access

The first thing to do is take the server out of the loop so no new traffic reaches it. If the server is behind a Load Balancer, remove it from the pool. If it has a public IP, you can enable the firewall or stop the web service. This prevents the situation from getting worse during the restoration.

Step 2: Choose the Restoration Method

You have two main methods:

• Restore on the same server: In this method, the current disk is replaced with the snapshot. This usually requires a reboot and may take a few minutes. In the ServerNet panel, there is typically a "Restore from Snapshot" option in the disk menu.
• Create a new server from the snapshot: If the current server is so broken that you don't want to take risks, create a new server with the same specifications from the snapshot, assign the IP to it, and then delete the old server. This method is safer.

My recommendation: always choose the second method, unless time is extremely critical for you. Creating a new server from a snapshot eliminates the risk of further damage.

Step 3: Health Check After Restoration

After restoration, check the following:

1. Is SSH access working?
2. Are the main services (MySQL, Nginx, PHP-FPM) healthy with systemctl status?
3. Is the database connectable and are critical data present?
4. Check the logs: journalctl -xe

If everything looks good, redirect traffic back to the server. If not, try another snapshot or fall back to periodic backups.

Managing the Lifecycle of Snapshots

Snapshots consume storage space and cost money. If you take several snapshots every day, your costs will quickly rise. Have a clear strategy:

• Delete temporary snapshots (taken before high-risk changes) after 24 to 48 hours, if everything went well.
• Keep weekly snapshots for 2 weeks.
• Keep monthly snapshots for 3 months.

In OpenStack, you can automate this with a cron job:

0 2 * * * openstack server image create --name "weekly-snapshot-$(date +\%Y\%m\%d)" --wait my-server && openstack image delete $(openstack image list --name "weekly-snapshot-" --format value -c ID | head -n -2)

This cron takes a snapshot every night at 2 AM and keeps only the last two. Note that \% in cron is used to escape %.

Common Mistakes and Solutions

Over the years of working with snapshots, I have repeatedly seen a few common mistakes that have led to data loss:

Mistake 1: Taking a Snapshot Without Stopping Write Operations

If your database is receiving transactions and you take a snapshot, the database files might be inconsistent, and after restoration, the database may not start. Solution: Before taking a snapshot, lock the database or use dedicated tools like mysqldump for a logical backup, and treat the snapshot as a second layer of protection.

Mistake 2: Not Testing the Snapshot

Many people take snapshots and never test them. When a crisis occurs, they realize the snapshot is corrupted or not bootable. Solution: Once a month, create a test server from the latest snapshot and make sure the services come up. This takes 10 minutes and prevents a disaster.

Mistake 3: Keeping Too Many Snapshots

Old snapshots not only cost money but also cause confusion — which one should I restore? Solution: Use standard naming with dates and reasons (e.g., pre-update-20250601) and regularly delete unnecessary snapshots.

Summary and Best Practices

A snapshot is a simple yet incredibly powerful tool that can mean the difference between a "minor incident" and a "complete disaster." Here is a summary of best practices:

• Take a snapshot before every high-risk change — always, without exception.
• Save snapshots with clear, date-based names.
• After restoration, always check the health of services.
• Test snapshots regularly.
• Combine snapshots with periodic backups, not as a replacement for them.

If you use the ServerNet cloud infrastructure, be sure to read the documentation on snapshots and custom images in the user panel — these features are usually built into the panel and make usage very simple. But more important than the tool is the habit: take a snapshot before making changes. This small habit can save your business.