Kopie zapasowe hostingu. Dwie warstwy, każdej nocy.

1. A backup that works before you need it

A backup is only useful if it exists when disaster strikes, not when someone merely promised it would. With Saplo, the Box backup is a snapshot of the entire LXC container, taken automatically at 4:00 AM. With no action required from you, you don't have to remember to export the database manually before every risky update.

Retention (the number of days a backup is kept) increases with the plan: Box L includes 7 days, Box XL includes 14 days, and Box XXL includes 30 days, plus an additional off-site copy created by a separate mechanism (Borg) every night at 1:00 AM to a remote location in Helsinki. This is independent of the local snapshot on the same server.

Box S and Box M do not include backups because they are entry-level plans for projects where backup costs would have to increase the price of the entire plan for every customer, even those who do not need backups, such as a test site or a portfolio with no dynamic data.

2. Two backup layers, not one

The local LXC snapshot (backup_limit in days) protects against the most common scenarios: a failed update, a broken plugin, or accidental deletion of your data. Restoring this snapshot is fast because it happens on the same physical server, with no data transfer over the network.

The off-site copy, available with Box XXL, protects against a much rarer but more serious scenario: the failure of an entire physical server or data center. The copy in Helsinki is physically separate from the production server in Falkenstein, so even the complete loss of the server does not mean the loss of your data.

The distinction between these two layers matters when choosing a plan. If your project is business-critical, such as a store handling real transactions or a SaaS application with paying customers, consider a plan with off-site backups, not just local snapshots.

3. Competitor backups: what is included and what costs extra

Competitor A offers up to 28 days of backup retention on root-access VPS plans, but restores are performed on request for an additional fee. This is because customers manage their servers themselves, and backups are treated as an add-on service rather than a fully automated process (public price lists and competitor plan description, as of 2026-10-10).

At the same provider, Windows VPS plans include daily full-server backups stored on an external server, with retention ranging from 7 to 28 days depending on the plan and additional features (public price lists, as of 2026-10-10). This is similar to Saplo's model, although it requires choosing a more expensive VPS plan.

Many shared hosting providers offer backups, but restoring from one may cost extra or be limited to a set number of restores per month. In practice, backups protect you against data loss, but they are not always free when you actually need them.

On Saplo plans that include backups (Box L, Box XL, Box XXL), there is no separate charge for restoring from a snapshot. It is part of the same automated process, not a paid support intervention.

4. Who it is for

For a test project or a portfolio without live data, backups are not critical because you can recreate the site from the code or Git repository if something goes wrong.

For an online store, CRM, or application with real customer data, backups stop being an option and become a necessity. Losing an order database or customer contacts has a direct business cost, not just an inconvenience.

For critical projects, such as SaaS products with paying customers or financial systems, consider Box XXL with off-site backups. A local snapshot on the same server cannot protect you from a failure of the physical server itself.

5. How restoring from a backup works in practice

You can restore a local snapshot through the Saplo panel by selecting the backup date and confirming the restore. In a typical scenario, you do not need to contact support because it is part of the automated backup process.

Because a snapshot includes the entire container, the restore brings everything back together, including files, the database, and the application configuration. This is simpler than manually restoring the database and files separately from two different sources.

With an off-site backup (Box XXL), restoring from the Helsinki location is slower than restoring a local snapshot because the data must be transferred over the network. However, it is the only option if your production server suffers a complete failure.

Test the restore process before you actually need it, for example on a copy of your application. This lets you know how long a restore takes and what to expect instead of learning during a real outage.

The backup history in the panel shows the date and time of each backup, so you can choose a specific day to restore, such as the day before a faulty plugin update broke your site.

6. Backups, GDPR, and client personal data

Backups of a database containing client personal data, such as store orders or CRM contacts, are subject to the same GDPR rules as production data, so it is worth knowing where the copy is physically stored and how long it is retained.

Backup retention of 7, 14, or 30 days, depending on the plan, means that data deleted from the live environment may still exist in the backup for that period. This matters when you need to comply with a request to erase personal data.

The off-site copy in Helsinki is physically separate from the production server in Falkenstein. You should consider this when assessing where customer personal data covered by backups is actually stored.

For businesses that process personal data at scale, such as stores, CRMs, and medical systems, a higher plan with longer retention and off-site backups provides better protection against data loss. You also need to know where those copies are physically stored.

7. Failure scenarios and what backups really protect against

The most common failure that backups protect against is human error, such as accidentally deleting a site, making a failed plugin update that corrupts the database, or deploying an untested code change to production.

The second scenario is an attack: a compromised site with injected malicious code. In this case, restoring from a copy taken before the infection is usually faster than manually cleaning every file and database entry to find the malicious code.

The third and rarest scenario is also the most serious, a failure of the physical server or data center. Only an off-site copy that is physically separate from the production server can protect against this, because a local snapshot on the same disk will not survive a failure of that disk.

For most small projects, the first two scenarios are far more likely than the third. A local snapshot (Box L, Box XL) therefore provides practical protection at a reasonable price, while an off-site backup (Box XXL) only makes sense for projects where even a rare but catastrophic server failure is unacceptable.

Backups also do not protect you against business errors, such as an incorrect price in a store or wrong email content sent to clients via automation. These errors are part of the data that a backup faithfully copies along with everything else, without distinguishing an error from the correct state.

Regularly checking, even briefly, that backups are running, such as by looking at the latest backup date in the panel, is a simple step that can identify a problem with the backup process before it becomes apparent at the worst possible time, when you need the backup most.

8. How Saplo communicates backup status to customers

Transparency around the backup process is just as important as having backups at all. You should be able to check when the last backup was taken at any time without asking support about your application's backup status.

The Saplo panel shows the history of completed backups with their dates, so you can verify that the mechanism is working properly yourself instead of relying solely on the claim in the terms that backups are performed regularly every night.

If there is a problem with the backup process, such as a snapshot that failed to run one night because of a technical issue, the Saplo team reports such incidents. This follows the principle that proof matters more than an assurance that everything is working as planned.

For business-critical projects, such as stores and applications with paying customers, regularly checking the backup status in the panel, even once a month, is good practice regardless of how reliably the automated process works day to day.

Clear information about which plans include backups and which require an add-on lets you make an informed choice when selecting a Box, instead of discovering that backups are missing only when you need them.

9. Backup as part of project risk assessment, not an add-on for later

When planning a new project, it is worth assessing right away how costly losing data would be at each stage of its development. For a site under construction, the cost is low because the code and content can be restored from the repository. For a store handling real orders, however, the cost of losing even a single day of data can be significant.

This assessment should shape your choice of Box plan from the start, rather than being postponed until the project already has real business value. At that point, switching to a plan with backups means adding an extra administrative step, even if it is a simple one, instead of including backups in your original choice.

For projects that grow gradually, starting as a simple website and later adding a store or booking system, the natural point to consider backups is the transition where the application starts storing data that would genuinely hurt to lose, rather than merely cosmetic website content.

It is also worth comparing the cost of backups included in a higher Box plan with the cost of making your own manual copies, such as exporting the database and archiving files. Although this is technically possible on every plan, it requires regular, hands-on discipline, which automated backups eliminate entirely.

The final decision on whether you need backups should always come from a realistic assessment of the value of the data stored in your application, not from the price of an add-on or a higher plan. The real risk factor is the value of the data you could lose, not the cost of backups.

10. In summary: backups as a deliberate choice, not an accident

Choosing a plan with backups included (Box L and above) or adding backups to a starter plan should be based on a deliberate assessment of the data stored in your application, not on chance or a lack of awareness of which plans include them. For a test project or portfolio, the risk is low. But for a store, CRM, or application with paying customers, backups are no longer optional and become part of your core responsibility for running the business, much like insurance or other standard protections against operational risk. The cost of a suitable plan with backups included is usually small compared with the cost of even one day of lost transactional data, making this one of the easier decisions to justify in the budget of any serious online project.