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

1. Une sauvegarde opérationnelle avant même que tu n'en aies besoin

Une sauvegarde n'est utile que si elle existe au moment de la panne, pas lorsque quelqu'un a promis qu'elle serait là. Sur Saplo, la sauvegarde Box est un instantané complet du conteneur LXC, réalisé automatiquement à 4 h 00 chaque nuit, sans intervention du client. Tu n'as donc pas à penser à exporter manuellement la base de données avant chaque mise à jour risquée.

La rétention (le nombre de jours pendant lesquels une copie est conservée) augmente avec le forfait: Box L conserve 7 jours, Box XL 14 jours et Box XXL 30 jours. Box XXL ajoute également une copie hors site réalisée par un mécanisme distinct (borg) chaque nuit à 1 h 00 vers un emplacement distant à Helsinki, indépendamment de l'instantané local sur le même serveur.

Box S et Box M n'incluent pas de sauvegarde dans leur tarif. Ce sont des formules d'entrée pour des projets où le coût de la sauvegarde aurait relevé le prix du plan pour tous les clients, même ceux qui n'en ont pas besoin (par exemple, un site de test ou un portfolio sans données à modifier).

2. Deux couches de sauvegarde, pas une seule

L'instantané LXC local (backup_limit en jours) protège contre le scénario le plus fréquent: une erreur lors d'une mise à jour, un plugin défectueux ou la suppression accidentelle de données par le client lui-même. La restauration est rapide, car elle s'effectue sur le même serveur physique, sans transfert de données via le réseau.

La copie hors site (disponible à partir de Box XXL) protège contre un scénario beaucoup plus rare, mais plus grave: la panne de l'ensemble du serveur physique ou du centre de données. La copie à Helsinki est physiquement séparée du serveur de production à Falkenstein. Même la perte totale du serveur ne signifie donc pas la perte des données de tes clients.

La distinction entre ces deux couches compte au moment de choisir un forfait: si le projet est critique pour l'activité (une boutique avec de vraies transactions, une application SaaS avec des clients payants), pense à un forfait avec sauvegarde hors site, et pas seulement à un instantané local.

3. Sauvegarde chez les concurrents: ce qui est inclus dans le tarif et ce qui doit être acheté séparément

Le concurrent A, sur ses offres VPS de type root, étend la durée de conservation des sauvegardes à 28 jours, mais la restauration depuis une copie est effectuée à la demande et facturée, car le client administre lui-même son serveur et la sauvegarde est traitée comme un service supplémentaire, et non comme un processus entièrement automatisé (tarifs publics, description de l'offre du concurrent, situation au 2026-10-10).

Sur les offres Windows VPS du même fournisseur, la sauvegarde complète du serveur est transférée chaque jour vers un serveur externe, avec une rétention de 7 à 28 jours selon le forfait sélectionné et les fonctionnalités supplémentaires (tarifs publics, situation au 2026-10-10). Le modèle est proche de celui de Saplo, mais il exige un forfait VPS adapté et plus cher.

Chez de nombreux fournisseurs d'hébergement mutualisé, la sauvegarde est disponible, mais la restauration peut être facturée en supplément ou limitée à un certain nombre de restaurations par mois. En pratique, la sauvegarde protège contre la perte de données, mais n'est pas toujours gratuite au moment où tu en as réellement besoin.

Sur Saplo, pour les offres qui incluent une sauvegarde (Box L, Box XL, Box XXL), aucun frais distinct n'est facturé pour la restauration depuis un instantané. Elle fait partie du même mécanisme automatique, et non d'une intervention de support payante séparée.

4. À qui cela s'adresse

Pour un projet de test ou un portfolio sans données à modifier, la sauvegarde n'est pas critique, car la restauration du site à partir du code ou du dépôt Git suffit en cas de problème.

Pour une boutique, un CRM ou une application contenant des données clients concrètes, la sauvegarde n'est plus une option, mais une nécessité, car la perte d'une base de commandes ou de contacts a un coût commercial direct, et pas seulement un désagrément.

Pour les projets critiques (SaaS avec des clients payants, systèmes financiers), il vaut mieux envisager Box XXL avec une copie hors site, car un instantané local sur le même serveur ne protège pas contre la panne du serveur physique lui-même.

5. À quoi ressemble la restauration d'une sauvegarde en pratique

La restauration depuis un instantané local se fait via le panneau Saplo: choisis la date de la sauvegarde et confirme la restauration. Dans un cas courant, tu n'as pas besoin de contacter le support, car cela fait partie du mécanisme automatisé de sauvegarde.

Comme l'instantané couvre l'ensemble du conteneur, la restauration porte sur tout à la fois: fichiers, base de données et configuration de l'application. C'est plus simple que de restaurer manuellement la base et les fichiers séparément à partir de deux sources différentes.

Avec une copie hors site (Box XXL), la restauration depuis le site d'Helsinki est plus lente que depuis un instantané local, car elle nécessite un transfert de données via le réseau. C'est toutefois la seule option en cas de panne totale du serveur de production.

Teste la restauration avant d'en avoir réellement besoin, par exemple sur une copie de test de l'application, afin de savoir combien de temps elle prend et à quoi t'attendre, plutôt que d'apprendre à le faire pendant une véritable panne.

L'historique des sauvegardes est visible dans le panneau, avec les dates auxquelles elles ont été effectuées. Tu peux ainsi choisir un jour précis pour la restauration, par exemple le jour précédant une mise à jour défectueuse d'une extension qui a cassé le site.

6. Sauvegarde, RGPD et données personnelles des clients

La sauvegarde d'une base de données contenant des données personnelles de clients (par exemple les commandes d'une boutique, les contacts CRM) est soumise aux mêmes règles du RGPD que les données en production. Il est donc utile de savoir où se trouve physiquement la copie et combien de temps elle est conservée.

La rétention des sauvegardes (7, 14 ou 30 jours, selon la formule) signifie que des données supprimées de la production par le client peuvent encore être présentes dans une sauvegarde pendant cette période. C'est important lors de la mise en œuvre du droit à l'effacement.

La copie hors site à Helsinki se trouve physiquement hors du serveur de production à Falkenstein. Il faut en tenir compte lorsqu'on évalue où les copies des données personnelles des clients couvertes par la sauvegarde sont réellement stockées.

Pour les entreprises qui traitent des données personnelles à grande échelle (boutiques, CRM, systèmes médicaux), une formule avec une rétention plus longue et une copie hors site offre une meilleure protection contre la perte de données, mais exige aussi de savoir où ces copies se trouvent physiquement.

7. Les scénarios de panne et ce que la sauvegarde protège réellement

La sauvegarde protège principalement contre l'erreur humaine: suppression accidentelle d'un site, mise à jour défectueuse d'une extension qui a corrompu la base de données, ou modification imprudente du code de l'application déployée sans tests en production.

L'autre scénario est une attaque: un site compromis auquel du code malveillant a été injecté. Restaurer depuis une copie antérieure à l'infection est généralement plus rapide que de nettoyer manuellement chaque fichier et chaque entrée de base de données à la recherche du code malveillant.

Le troisième scénario, le plus rare mais le plus grave, est la panne du serveur physique ou du centre de données. Seule une copie hors site, physiquement séparée du serveur de production, protège contre ce scénario, car un instantané local sur le même disque ne survit pas à la panne de ce disque.

Pour la plupart des petits projets, les deux premiers scénarios sont bien plus probables que le troisième. Un instantané local (Box L, Box XL) assure donc une protection réelle à un prix raisonnable, tandis qu'une copie hors site (Box XXL) n'a de sens que pour les projets où même une panne serveur rare mais catastrophique est inacceptable.

Il faut aussi garder à l'esprit qu'une sauvegarde ne protège pas contre les erreurs métier (un prix erroné dans une boutique, le contenu erroné d'un e-mail envoyé aux clients par une automatisation), car ces erreurs font partie des données que la sauvegarde copie fidèlement avec le reste, sans distinguer l'erreur de l'état correct.

Vérifier régulièrement, même de façon sommaire, que la sauvegarde s'effectue bien, avec la date de la dernière sauvegarde visible dans le panneau, est une simple mesure qui permet de détecter un dysfonctionnement avant qu'il ne se manifeste au pire moment, c'est-à-dire précisément quand la sauvegarde est le plus nécessaire.

8. Comment Saplo communique le statut de la sauvegarde au client

La transparence du mécanisme de sauvegarde est aussi importante que le simple fait qu'il existe: tu dois pouvoir vérifier à tout moment quand la dernière sauvegarde a été effectuée, sans avoir à contacter le support pour connaître le statut de la sauvegarde de ton application.

Le panneau Saplo affiche l'historique des sauvegardes effectuées avec leurs dates, ce qui te permet de vérifier toi-même le bon fonctionnement du mécanisme, au lieu de te fier uniquement à l'affirmation des conditions générales selon laquelle la sauvegarde est réalisée régulièrement chaque nuit.

En cas de problème avec le mécanisme de sauvegarde, par exemple un instantané qui n'a pas été effectué une nuit à cause d'un incident technique, l'équipe Saplo informe les clients de ces incidents. C'est conforme au principe selon lequel les preuves comptent davantage que la simple garantie que tout fonctionne comme prévu.

Pour les projets critiques pour l'activité (boutiques, applications avec des clients payants), vérifier soi-même régulièrement le statut de la sauvegarde dans le panneau, même une fois par mois, est une bonne pratique, quel que soit le bon fonctionnement quotidien du mécanisme automatique.

Des informations claires sur les formules qui incluent une sauvegarde et celles qui nécessitent un supplément permettent de choisir une formule Box en connaissance de cause, plutôt que de découvrir l'absence de sauvegarde au moment où l'on en a besoin.

9. La sauvegarde dans l'évaluation des risques du projet, pas comme option à ajouter plus tard

Lors de la planification d'un nouveau projet, évalue tout de suite le coût d'une perte de données à ce stade de son développement: pour un site en construction, le coût est faible, car le code et le contenu peuvent être restaurés depuis le dépôt, mais pour une boutique qui traite de vraies commandes, la perte d'une seule journée de données peut avoir un impact financier important.

Cette évaluation doit guider le choix de la formule Box dès le départ, et ne pas être repoussée jusqu'à ce que le projet ait une réelle valeur commerciale. À ce stade, la migration vers une formule avec sauvegarde demande une démarche administrative supplémentaire, même simple, alors qu'elle pourrait faire partie du choix initial.

Pour les projets qui évoluent progressivement (un simple site au départ, puis l'ajout d'une boutique ou d'un système de réservation), le bon moment pour envisager la sauvegarde est précisément le point de transition où l'application commence à stocker des données dont la perte aurait des conséquences réelles, au-delà du seul contenu décoratif du site.

Le coût de la sauvegarde incluse dans les plans Box de niveau supérieur mérite aussi d’être comparé au coût d’une sauvegarde manuelle (export de la base de données, archivage des fichiers). Bien que cette pratique soit techniquement possible sur tous les plans, elle exige une discipline que le mécanisme automatique de sauvegarde supprime complètement.

La décision finale sur la nécessité d’une sauvegarde doit toujours reposer sur une évaluation réaliste de la valeur des données stockées dans l’application, et non sur le seul prix de l’option ou du plan supérieur. Le facteur de risque réel est en effet la valeur des données perdues, pas le coût de la sauvegarde.

10. Résumé: la sauvegarde est un choix conscient, pas un hasard

Le choix d’un plan où la sauvegarde est incluse (Box L et au-delà), ou son ajout en option à un plan initial, doit découler d’une évaluation consciente de la valeur des données stockées dans chaque application, et non du hasard ou du fait de ne pas savoir quels plans incluent une sauvegarde. Pour un projet de test ou un portfolio, le risque est faible, mais pour une boutique, un CRM ou une application avec des clients payants, la sauvegarde n’est plus une option. Elle fait partie de la responsabilité fondamentale de l’activité, au même titre qu’une assurance ou toute autre protection standard contre les risques opérationnels. Le coût du plan adapté, sauvegarde incluse, est généralement faible comparé au coût d’une seule journée de données transactionnelles perdues. C’est l’une des décisions les plus faciles à justifier dans le budget de tout projet en ligne mené avec sérieux.