A snapshot is a point-in-time representation with protection determined by its implementation. A backup strategy adds deliberate retention, access separation and tested recovery. Some snapshots are backups; others depend on the original storage. Ask what survives deletion, compromise or loss of the primary environment.
Describe the copy before naming it
The word snapshot tells you that a point in time has been represented, but not where the recoverable data is held or who can delete it. A filesystem snapshot on the original storage and a provider-managed block snapshot can have different failure boundaries. Start with the implementation rather than treating the label as a universal promise.
AWS documents EBS snapshots as incremental point-in-time backups of its volumes. That is a specific implementation, not proof that every snapshot option behaves the same way. For any service, ask whether restoration depends on the original volume, whether copies leave the primary failure domain and what happens when the source is removed.
Compare the failures you expect to survive
A quick rollback after an update and recovery after losing an account are different problems. A local snapshot may be convenient for the first while offering little separation for the second. Independent copies can add protection, but only if their storage, access and deletion paths are sufficiently separate from the incident you are preparing for.
Write down the failure and the required outcome. This illustrative comparison is a decision aid, not a feature list for SwissOctet. It encourages questions about copies and control rather than a claim that one technology is always superior. The actual outcome depends on configuration and the operator's documented recovery process.
| Scenario | Question for a snapshot | Question for a backup |
|---|---|---|
| Bad application update | Can I return to the intended point? | How long does a usable restore take? |
| Primary disk lost | Does the copy depend on that disk? | Can I restore onto fresh storage? |
| Administrative account compromised | Can this account delete every copy? | Are deletion rights separated? |
| Error discovered weeks later | Is that point still retained? | Does retention cover the discovery delay? |
Check application consistency
A disk can capture files while an application is still changing them. Depending on the software and snapshot process, the result may represent a crash-consistent state rather than a coordinated application state. Do not assume that readable files mean a database and its related uploads agree. Use the backup method documented by the application or database.
PostgreSQL's continuous-archiving design illustrates the difference: recovery needs a suitable base backup and a continuous sequence of the required write-ahead log files. A directory copied casually while the database runs is not an equivalent procedure. If the application also stores files outside the database, plan how those two datasets are recovered together.
Treat retention as a recovery window
Retention should account for how long an error can remain unnoticed. A ten-day window does not help an accidental deletion discovered after a month. Keeping every copy indefinitely creates a different problem: cost, growing sensitive-data exposure and an unclear deletion policy. Choose retention from concrete operational and data-handling requirements.
Label recovery points with useful context, such as application version and completed job time, without embedding secrets. Keep enough history to distinguish a good state from a damaged one. Before pruning, confirm how the chosen system handles shared or incremental data; deleting a labelled point may not correspond to deleting a simple standalone file.
Separate successful jobs from verified data
A backup tool reporting success establishes that its process completed under its rules. It does not automatically prove that all important application data was selected, every stored byte remains intact or a new server can use the result. Those are different checks. Include repository health, selection review and representative restoration in the operational plan.
Restic documents a distinction between its default repository check and verification that reads stored pack data. The full data-reading check can consume more time and bandwidth. That example makes the planning point concrete: decide what verification actually reads and budget the work. Use tool documentation rather than assuming every command named check has the same coverage.
Test a small, complete recovery
Imagine a publication with a database, uploaded images and configuration. Restore all three into a private test environment, then open an article and verify its attachments. Keep scheduled mail, payment and publishing integrations disabled during the exercise. Testing only a random text file would miss the relationships that make the application useful.
Measure the time required and record which credentials, package versions or external dependencies were missing. Review permissions on the recovered files, not only their contents. A recovery exercise often discovers that the data exists but the instructions or access needed to use it have never been preserved alongside the operating plan.
Read optional backups as a specific service
When configuring SwissOctet, look at the exact backup option and retention period for the family. Ask which volumes and application data it covers, whether recovery is self-service and what happens when the primary configuration changes. The option label alone does not establish an independent copy, an immutable repository or a database-consistent recovery point.
Use snapshots where they fit the workload and keep a broader backup strategy for failures they do not cover. Record an independent recovery route for important data, protect the credentials that can erase copies and test the procedure. The strongest choice is the one that survives your defined scenario, not the one with the most reassuring name.
Your practical checklist.
- Identify where the recoverable data lives.
- List failures the copy must survive.
- Use an application-supported consistency method.
- Choose retention for the discovery window.
- Protect deletion rights separately.
- Restore a complete application in isolation.
The details that matter.
Is a snapshot never a backup?+
Some snapshot implementations are backups. The useful distinction is their storage dependency, retention, access model and tested recovery, not the label alone.
Does a successful integrity check prove the application will work?+
It proves only what that check covers. Test application restoration, configuration, permissions and data relationships separately.
Should I keep the backup on the same server?+
A same-server copy may help with limited mistakes but shares important failures. Important data needs a recovery route outside the failure boundary you intend to survive.
Go to the source.
These references support the technical concepts in this guide. Follow the current documentation before changing a production system.
- Amazon EBS: Snapshots docs.aws.amazon.com
- PostgreSQL: Continuous archiving and point-in-time recovery www.postgresql.org
- Restic: Working with repositories and integrity checks restic.readthedocs.io
Editorial guidance by SwissOctet. Examples are illustrative. Service specifications, available options and contractual conditions must be verified separately.