Summary of the story: "I've had enough. . . . " . Snapshots and backups are often used interchangeably, but they serve different purposes: a snapshot is used for quick rewinding of the same disk; a backup is used to replicate data to different fault domains. This spreadsheet collates nature, storage location, recovery speed, risk coverage and cost, and gives website programs packages, MySQL separate exports, object-stored alias copies, quarterly restore drills, etc., methods that help site builders develop tests and foreign trade businesses judge when it's necessary to rely solely on snapshots, and when independent backing up is required.
Key takeaways from the report: "We are not alone. . . . " . data center provides a snapshot function and still needs its own backup. The snapshot solution is that if the disk was just working properly, now it has been damaged, can you quickly go back to the tray? The backup solution is to restore data elsewhere when this machine, this storage cluster, this account or even this server are not available.
What is it: what do snapshots and backup solve?
| Dimensions | A snapshot | Backed up |
|---|---|---|
| What it is | A snapshot of the disk's state at a given time | Copies of data stored separately |
| Location | Usually with source disk identical to data center , storage cluster or server system | The bucket should be stored on another machine, object or server. |
| Speed of recovery | Second to minute scale for fast rewind | slower, depending on the amount of data, bandwidth , storage type and recovery mode |
| Prevention of what? | Failure to operate, upgrade failure, system malfunction or misconfiguration | data center Failure, account issue, server shutdown and general unavailability of the source environment |
| Typical restrictions | Limited quantity and retention time, mostly charged | Costs mainly in storage with bandwidth |
| What is appropriate? | Regret before change, short-term relapse | Long-term retention, relocation and business resilience bottlenecks |
A snapshot is more like a roll-back switch on the same disk. It usually relies on the original storage system, and when restored it can be pulled directly back to a certain point in time, so it's very fast. Backing up is much more like pulling another copy of data from the hard drive. The focus isn't on recovery speed but rather ensuring that copies are not in the same fault zone as the source environment.
The difference between the two directly affects recovery targets for construction sites, development testing and foreign trade operations:
- If the problem is a system upgrade failure, an error in deleting the configuration folder, or an abnormal pop-up on the site page, snapshots can usually compress recovery time to a shorter range.
- If the problem is that an account has been blocked or locked by a cluster of storage abnormalities, or if the server stops working and both source disk and snapshot are unavailable, then it's not enough to just use snapshots.
- The industry standard 3-2-1 rule can be used as a benchmark: at least three copies, stored on two different mediums, one of which is off-site. This is not just another directory, but far from the same machine, server or fault zone.
How to choose: Depending on the recovery goal, backup
| The scene | Recommended practice | Why? |
|---|---|---|
| Just upgraded, changed the Nginx/ PHP /database configuration and deployed a new version | Take a snapshot manually and then make changes. | Quickly re-rolled after repairs, suitable for cooking remorse meds |
| Program files, uploaded attachments and static resources | Incremental backups are packaged daily at regular intervals, and then encrypted for transmission to object storage or another VPS | File-type data is suitable for packet archiving, decentralized copying reduces single point risk |
| MySQL from the database | Use mysqldump or physical backup tools to export separately, not just copy data directory files | Direct copied data directory may encounter file inconsistencies, engine failures and recovery corruption |
| Foreign trade, customer and order data | Exporting the database + wrapping of program files + off-site storage + periodic recovery drills | This kind of data loss affects delivery, accounts and customer trust. You can't just rely on data center snapshot |
| Development of a test environment | Snapshots, regular backups of key test data | The development environment can be rebuilt, but the script, configuration and sample data are still valuable |
| Production environment | Snapshots for quick rewind, backups to use in disaster relief | It's not the same, but it is necessary. |
Low-cost local cases
- Separate processing of the website program from the database
Website programs, images and uploaded files can be backed up; databases should not only copy directory files but logical exports or physical backup tools. MySQL is available with mysqldump or a physical backup tool depending on the amount of data, consistency requirements and recovery speed
- Temporary incremental backups to separate storage
Perform a daily backup, exporting the encrypted files of the website program and database to object storage or another VPS . The key here is to stay away from the open source machine instead of continuing with the backup file in the same server directory.
- Snapshot for changing the window
Take a manual snapshot before upgrading the system, making major configuration changes, installing plugins or migrating sites. If there are serious anomalies within minutes of any change, you can quickly roll back to your pre-change state.
- Back-up copy retention policy to be planned separately
There is a limit on the number of snapshots and storage time, most are charged. Backup should also set up retention periods: nearly 7 days, almost 30 days, nearly 12 months etc.
- Do a recovery exercise every quarter.
A backup that has not been restored is equivalent to no backups at all. Every quarter, a full recovery test is performed in an isolated environment to verify that the program can be started, the database can be imported, and key pages are accessible.
Note: Common pits and checklists
Common pit
| Common misconceptions | The Real Risk | How to fix it |
|---|---|---|
| Don't back up with a snapshot | The snapshot and source disk are often in the same fault zone, data center , accounts, storage clusters or servers may not be accessible when there is an overall anomaly | Transfer a copy of the data to another machine or server |
| Backup only the site directory, not the database | The site appears to be open, but orders, users, products and articles may not be complete. | Separate backup of program files and database exports |
| Direct copy of MySQL directory data | File inconsistencies, table corruption and engine abnormalities | Using mysqldump or physical backup tools |
| Backup files not encrypted | Sensitive data may be exposed if off-site storage is accessed incorrectly | Backup pre-encrypted, keys stored separately from backup files |
| Backup credentials with server | When server is controlled, backup accounts may also be deleted or tampered with | Use separate accounts, separate access keys and rotate regularly |
| Never tested again | Backup files may be corrupted, formatted incompatibly or missing dependencies | A quarterly backup for full recovery testing |
Checklists
- Does the backup run automatically and notify you if it fails?
- Did the copy leave the source machine and server?
- Is the backup encrypted?
- Are the accounts, keys and credentials required to access a backup separate from server ?
- How long will it take to recover?
- Is this recovery time within business tolerance?
- When was the last resumption exercise?
- Are the number of snapshots retained, retention time, replication capacity and recovery billing across data center clear?
The number of snapshots that can be retained, whether cross-regional replication is supported, whether recovery charges are charged and if the account has been restricted from accessing a snapshot varies widely depending on the service provider. These capabilities should be based on official statements.
FAQ and
1. data center Can snapshots replace backups?
Cannot. Snapshots are usually in the same fault zone as the source disk for quick rollback; a core value of backups is to move data away from the current machine, storage cluster or server system.
2. Does taking a snapshot every day equate to making daily backups?
If the snapshot and source disk are from the same server, account or storage cluster, they may not be available together in case of a data center failure, account issue or server shutdown.
3. MySQL Is it possible to directly copy the data directory for backup?
It is not recommended. Direct copying of data directory files is prone to inconsistencies or corruption. Use mysqldump or a physical backup tool, and periodically verify successful recovery.
4. How long is a practice session appropriate?
Perform a full recovery test with at least one backup every quarter. Scenarios where business is more sensitive and data changes are more frequent should be rehearsed more often.
5. How should the work be divided between snapshots and backups?
Snapshots are responsible for fixing the broken fast rollback, and backups are in charge of locking the environment without data. The two together form a more complete closed loop to protect data.
This post was last updated on: May 06, 2016 at 1:05 pm. . . 2026-06-22 This is not the time.
The nucleus of information is for the following: . . . , . . .. . . 2026-06-22 This is not the time.
This post is part of our special coverage Africa Day. data center with disk backup schematics, including server , storage blocks, network connections and map elements. No text, no branded logos or real people
This post is part of our special coverage Africa.
- VPS Data backup: object storage and incremental packaging process
- MySQL database export:mysqldump Differences from physical backups
- Cloud disk snapshot feature: preservation policy and recovery speed
- Foreign trade business server : procedures and databases separated from backups
- VPS Failure area: data center , account and storage cluster risk
Reader comments (0)