Sauvegardes

Les sauvegardes automatiques sont incluses à partir des offres intermédiaires, avec une fréquence qui augmente sur les offres supérieures. Sur VPS, elles dépendent du plan et des options. Le détail figure par offre sur les pages produits.

Oui, une option de backup quotidien premium est disponible pour renforcer la protection de vos données au-delà de ce qu'inclut votre plan.

Selon votre plan, vous pouvez restaurer depuis cPanel. Dans les autres cas, notre support effectue la restauration à votre demande.

La durée de rétention dépend de votre plan et des options. Contactez le support pour connaître la rétention applicable à votre offre.

Oui, les snapshots sont disponibles selon le plan VPS (VPS Power et VPS Business). Ils permettent de figer l'état du serveur avant une opération sensible.

Vous disposez d'un accès root : vous pouvez automatiser vos sauvegardes avec des outils comme rsync, restic ou borgbackup, vers un stockage distant de votre choix.

Combinez un export des volumes Docker avec un outil de sauvegarde incrémentale comme Restic ou BorgBackup. Arrêtez temporairement le conteneur (ou utilisez `docker exec` pour un dump propre des bases de données), compressez le volume, puis envoyez l'archive vers un stockage distant. Planifiez l'opération via cron ou un pipeline CI/CD, et versionnez vos fichiers `docker-compose.yml` et `.env` dans un dépôt git privé.

Les sauvegardes incluses dans vos offres d'hébergement sont conservées dans l'infrastructure ServOrbit. Depuis un VPS, vous pouvez configurer Restic ou BorgBackup pour envoyer des copies hors site chiffrées vers S3, Backblaze B2, Scaleway Object Storage ou un serveur SFTP de votre choix. Cette approche est fortement recommandée pour toute donnée critique. Des templates prêts à l'emploi pour ces outils sont disponibles dans le Marketplace ServOrbit.

Oui pour MySQL et MariaDB : dans l'espace client (VPS → Gérer → Bases de données), vous activez un planning quotidien ou hebdomadaire, choisissez l'heure et la durée de conservation, et les archives sont déposées sur votre espace de sauvegarde. Une sauvegarde immédiate est également disponible, confirmée par votre mot de passe et un code à usage unique — utile juste avant une opération sensible comme une montée de version majeure du moteur. Les autres moteurs (PostgreSQL, MongoDB…) ne sont pas détectés par cet outil : prévoyez votre propre export et envoyez-le vers un stockage distant.

Oui, sur les hébergements cPanel ServOrbit, JetBackup permet une restauration granulaire : vous sélectionnez précisément le fichier ou le dossier à restaurer depuis la liste des sauvegardes disponibles, sans toucher au reste de votre compte. Pour les VPS et serveurs dédiés, les snapshots permettent également deux niveaux de restauration : une restauration complète de l'image disque ou une exploration du snapshot pour en extraire uniquement les fichiers souhaités. Cette flexibilité évite d'écraser des données récentes lors de la récupération d'un seul élément.

Restic intègre la commande `restic check` qui parcourt le dépôt et détecte toute corruption des blocs chiffrés, sans avoir à restaurer les données. Planifiez cette vérification via un timer systemd ou une cron hebdomadaire, et redirigez sa sortie vers un canal d'alerte (mail, webhook n8n, ntfy). Si la commande retourne un code non nul, une restauration de test sur un répertoire temporaire confirme rapidement la récupérabilité réelle de vos données avant qu'un incident ne survienne.

Dans cPanel, JetBackup permet une restauration vers un dossier de destination différent plutôt que d'écraser l'emplacement d'origine. Choisissez l'option « Restaurer vers » et indiquez un répertoire temporaire ; vous pouvez ainsi comparer les fichiers restaurés avec ceux en production avant tout basculement. Cette méthode garantit que votre site reste disponible pendant la vérification. Si vous avez besoin d'accompagnement, ouvrez un ticket depuis votre espace client.

Un snapshot VPS est une image instantanée de l'ensemble du disque de votre serveur, idéale avant une opération risquée ; il est stocké sur la même infrastructure et peut être restauré rapidement. JetBackup (disponible sur l'hébergement cPanel) propose des sauvegardes incrémentales automatiques de vos fichiers, bases de données et e-mails, stockées sur un espace distant, avec restauration fichier par fichier depuis cPanel. Pour une protection complète sur VPS, combinez snapshots et une solution de sauvegarde externe (Restic, BorgBackup).

Plusieurs approches existent selon le niveau de granularité souhaité. La méthode la plus directe consiste à utiliser `docker run --rm -v <volume>:/data alpine tar czf - /data` pour archiver un volume dans un fichier, puis à transférer ce fichier vers un stockage externe via `rsync` ou `rclone` (compatible S3, SFTP, etc.). Pour une sauvegarde cohérente des bases de données, préférez un dump applicatif (`pg_dump`, `mysqldump`) plutôt qu'une copie brute du volume. Automatisez ces sauvegardes avec un cron quotidien et conservez plusieurs générations. ServOrbit propose également des snapshots VPS planifiables depuis l'espace client, utilisables comme filet de sécurité complémentaire.

Oui, il est tout à fait possible de restaurer une sauvegarde d'un VPS sur un autre VPS, par exemple pour migrer vers une offre plus puissante ou pour créer un environnement de reprise après sinistre. **Avec JetBackup** (licence en option à 119 DH/mois, sur un serveur équipé de cPanel) : connectez-vous à l'interface JetBackup, sélectionnez la sauvegarde à restaurer, et choisissez **Restauration vers un autre serveur**. Renseignez l'adresse IP du VPS de destination et les identifiants SSH. JetBackup transfère et restaure automatiquement les données. **Sans JetBackup** : exportez votre sauvegarde (snapshot ou archive tar) depuis l'espace client, téléchargez-la sur le VPS de destination via `rsync` ou `scp`, puis restaurez manuellement. Notez que les adresses IP changent lors d'une migration : pensez à mettre à jour vos DNS et vos configurations applicatives après la restauration.

Les volumes Docker sont l'endroit où vos applications Docker stockent leurs données persistantes (bases de données, fichiers uploadés, configurations). Voici les trois approches pour les sauvegarder. **Approche 1 — Sauvegarde directe du répertoire de volume** : les volumes Docker sont stockés dans `/var/lib/docker/volumes/`. Chaque volume est un répertoire nommé. Vous pouvez les sauvegarder directement avec `tar` : `tar czf /sauvegarde/monvolume-$(date +%Y%m%d).tar.gz -C /var/lib/docker/volumes/monvolume/_data .` **Approche 2 — Export via conteneur temporaire** (recommandée) : cette approche fonctionne sans connaître le chemin physique du volume : `docker run --rm -v monvolume:/data -v /sauvegarde:/backup alpine tar czf /backup/monvolume-$(date +%Y%m%d).tar.gz -C /data .` **Approche 3 — Snapshot de l'application** (pour les bases de données) : utilisez l'outil natif de la base de données pour exporter un dump cohérent avant de sauvegarder. Par exemple, pour PostgreSQL dans un conteneur : `docker compose exec -T db pg_dump -U utilisateur ma_base | gzip > /sauvegarde/db-$(date +%Y%m%d).sql.gz` Pour automatiser, ajoutez la commande dans un script et planifiez-la avec cron. Synchronisez ensuite vers un stockage distant avec rclone pour une protection hors-site.

Oui : avant toute mise à jour majeure d'une application self-hosted (CMS, outil financier, serveur mail…), effectuez une sauvegarde complète des fichiers et de la base de données — même si votre VPS bénéficie déjà de sauvegardes automatiques planifiées. Une sauvegarde ponctuelle prise juste avant la mise à jour vous permet de revenir à un état stable connu en quelques minutes en cas d'incompatibilité. La fréquence des sauvegardes automatiques incluses varie selon votre plan ServOrbit ; consultez /tarifs pour les détails par offre.

Un bare clone (`git clone --bare <url>`) copie l'intégralité de l'historique, des branches et des tags sans working tree, ce qui en fait le format idéal pour l'archivage et la restauration. Depuis votre VPS, planifiez une tâche cron qui exécute `git clone --mirror` vers un répertoire de sauvegarde, puis compressez et transférez l'archive vers un stockage externe (S3, SFTP). Pour aller plus loin, notre guide sur l'auto-hébergement de Gitea est disponible sur `/vps-cloud`.

Avant toute mise à jour, archivez les répertoires `/etc/postfix/` (configuration principale), `/etc/opendkim/` ou `/etc/dkim/` (clés DKIM) et le fichier `/etc/aliases`. Utilisez `tar -czf postfix-backup-$(date +%F).tar.gz /etc/postfix /etc/opendkim` puis transférez l'archive vers un emplacement hors du serveur avec `rsync` ou `scp`. Conservez également les enregistrements DNS TXT correspondants pour pouvoir republier les clés en cas de perte. Contactez notre support via [email protected] si vous avez besoin d'une assistance à la restauration.

Pour PrivateGPT, sauvegardez le dossier `local_data/` (documents indexés et base vectorielle) ainsi que le fichier de configuration `settings.yaml`. Pour LocalAI, archivez le répertoire des modèles (généralement `models/`) et les éventuels fichiers de configuration YAML des profils. Planifiez une tâche `rsync` ou utilisez Restic pour transférer ces dossiers vers un stockage externe ; les fichiers de modèles peuvent être volumineux, pensez à les dédupliquer. Retrouvez nos templates PrivateGPT et LocalAI sur la Marketplace ServOrbit via `/vps-cloud`.

Arrêtez d'abord le conteneur Mattermost (`docker compose stop mattermost`) pour éviter toute écriture en cours, puis exécutez un dump : `docker exec mattermost-db pg_dump -U mmuser mattermost | gzip > mattermost-backup-$(date +%Y%m%d).sql.gz`. Conservez l'archive hors du VPS (stockage objet, transfert `scp`/`rsync`) avant de lancer la mise à jour. Pour restaurer : `gunzip -c mattermost-backup-YYYYMMDD.sql.gz | docker exec -i mattermost-db psql -U mmuser mattermost`. L'option de sauvegarde ServOrbit prend un snapshot disque complet — activez-la en complément pour couvrir également les volumes de fichiers.

Par défaut, Chatwoot stocke les fichiers uploadés dans le dossier `storage/` du conteneur — ces fichiers sont perdus si le conteneur est recréé. Cloudflare R2 est compatible S3 et s'utilise sans frais d'egress. Attention : une incompatibilité entre Active Storage (Rails) et R2 provoque une perte silencieuse des pièces jointes (issue chatwoot#13299) — les fichiers semblent téléversés mais s'affichent avec « This image is no longer available ». Le correctif consiste à ajouter `request_checksum_calculation: "when_required"` et `response_checksum_validation: "when_required"` dans le bloc de service R2 de `config/storage.yml`. Configurez ensuite les variables `ACTIVE_STORAGE_SERVICE=amazon`, `S3_BUCKET_NAME`, `S3_REGION`, `S3_ACCESS_KEY_ID`, `S3_SECRET_ACCESS_KEY` et `S3_ENDPOINT` dans votre `.env` Chatwoot. Redémarrez les conteneurs et testez l'envoi d'un fichier depuis un ticket pour valider.

Docmost stocke ses données dans une base PostgreSQL et ses fichiers (images, pièces jointes) dans un volume Docker ou un stockage objet compatible S3. Pour une sauvegarde complète avant toute migration ou mise à jour majeure : (1) exécutez `pg_dump -U docmost docmost > docmost_backup_$(date +%Y%m%d).sql` sur la base Docmost, (2) archivez le volume de stockage de fichiers Docker (`docker run --rm -v docmost_storage:/data -v $(pwd):/backup alpine tar czf /backup/docmost_files_$(date +%Y%m%d).tar.gz /data`) ou exportez votre bucket R2/S3. (3) Planifiez cette sauvegarde dans un script cron sur votre VPS et envoyez les archives vers un stockage externe (S3, Backblaze B2 ou SFTP) pour éviter de stocker sauvegarde et données sur le même disque.

Stalwart stocke ses données dans un répertoire configurable (par défaut `/opt/stalwart-mail/data`) : il suffit d'arrêter le service, de copier ce dossier vers un stockage distant avec Restic ou BorgBackup, puis de redémarrer. Veillez à inclure les certificats TLS (Let's Encrypt ou personnalisés), les clés DKIM (sous-dossier `dkim/`) et le fichier de configuration `config.toml`. Pour les installations Docker, montez le dossier de données en volume nommé et sauvegardez ce volume. Planifiez la sauvegarde quotidienne via cron et vérifiez périodiquement la restauration sur un VPS de test.

La fréquence des sauvegardes doit être proportionnelle à votre **RTO (Recovery Time Objective)** et **RPO (Recovery Point Objective)** — combien de temps vous pouvez vous permettre d'être arrêté, et combien de données vous pouvez vous permettre de perdre. **Recommandations pratiques :** | Type de site | Fréquence | Rétention | |---|---|---| | Vitrine statique | 1×/semaine | 4 semaines | | Blog actif | 1×/jour | 30 jours | | E-commerce | 4×/jour | 30 jours + 3 mois mensuels | | Application critique | 1×/heure | 48h horaires + 30j quotidiens | **Où stocker les sauvegardes — règle 3-2-1 :** - **3** copies des données - Sur **2** supports différents - Dont **1** en dehors du site principal Concrètement : snapshot sur le même VPS (rapide à restaurer) + copie vers un bucket S3 ou un autre VPS (protège contre la panne du serveur principal). **Ce que ServOrbit propose :** snapshots quotidiens automatiques inclus dans les plans VPS, avec rétention configurable. Les données restent en Europe.

Avant toute opération sensible sur Plane, sauvegardez les volumes Docker de l'application. La commande `docker compose exec plane-db pg_dump -U plane plane > plane_backup.sql` exporte la base principale ; complétez avec une copie des fichiers de configuration (`.env`, `docker-compose.yml`) et des éventuels uploads stockés sur disque. Testez la restauration sur un environnement de test avant de procéder à la migration.

Oui, c'est indispensable : une mise à jour de version majeure de PostgreSQL (ex. 15 → 17) modifie le format interne des données et ne peut pas être annulée sans restauration. Avant toute migration, exportez un dump complet avec `pg_dumpall -U postgres > backup_avant_migration.sql` et conservez-le sur un stockage distinct de votre VPS (Backblaze B2, SFTP distant). Vérifiez que la restauration fonctionne sur un environnement de test avant de couper l'ancien moteur. Si vous utilisez l'option sauvegarde premium de ServOrbit, confirmez que le dernier snapshot est récent avant de lancer la procédure.

Elasticsearch dispose d'une API Snapshot and Restore qui génère des sauvegardes incrémentielles dédupliquées de vos index. Configurez un repository S3 (compatible Backblaze B2, Cloudflare R2 ou tout stockage objet S3-compatible) et définissez une Snapshot Lifecycle Policy (SLM) pour automatiser la fréquence et la rétention. Important : ne copiez jamais les fichiers de données directement sur le disque pendant qu'Elasticsearch tourne — seul le mécanisme natif de snapshot garantit une sauvegarde cohérente. Testez une restauration sur un second VPS régulièrement pour valider l'intégrité.

Pour un VPS en production, visez au minimum une sauvegarde quotidienne avec une rétention de 7 jours. Les applications critiques (bases de données, fichiers clients) méritent des sauvegardes horaires ou incrémentales. Distinguez les snapshots système (utiles avant une mise à jour) des sauvegardes de données (essentielles pour la continuité). Testez régulièrement la restauration : une sauvegarde dont la restauration n'a jamais été vérifiée est une sauvegarde non fiable. Stockez les copies sur un site distant ou un service d'objets indépendant de votre VPS.

Un snapshot est une photo de l'état du disque à un instant précis, prise au niveau hyperviseur : rapide à créer, il permet de revenir en arrière en quelques minutes, mais reste lié au même stockage physique. Une sauvegarde complète copie les données vers un emplacement distinct (autre serveur, stockage objet) et protège contre une panne matérielle. Les deux sont complémentaires : le snapshot couvre les erreurs humaines et les mises à jour ratées, la sauvegarde couvre les sinistres et les pertes de données. Sur un VPS ServOrbit, les snapshots et les sauvegardes automatiques sont disponibles selon le plan.

ERPNext génère des sauvegardes compressées via `bench backup` dans le dossier `private/backups/` de chaque site. Combinez ce mécanisme avec `rclone` ou l'outil AWS CLI pour pousser chaque archive vers un bucket S3 compatible (Backblaze B2, Cloudflare R2, MinIO…) juste après sa création. Planifiez l'ensemble avec un cron nocturne, chiffrez les archives côté client avant l'envoi si elles contiennent des données sensibles, et testez régulièrement la restauration sur un environnement de test pour valider leur intégrité. Conservez au minimum 7 copies quotidiennes et 4 copies hebdomadaires.

Connectez-vous à votre espace client ServOrbit, ouvrez un ticket de support en catégorie « Hébergement » et précisez la date de la sauvegarde souhaitée ainsi que le chemin ou la base de données à restaurer. Notre équipe effectue la restauration depuis les snapshots JetBackup dans les plus brefs délais. Si vous disposez de JetBackup en option, vous pouvez également déclencher la restauration vous-même depuis l'interface cPanel, sans passer par le support.

Un snapshot est une copie instantanée du disque réalisée au niveau de l'hyperviseur : idéal pour revenir en arrière après une fausse manipulation, mais il réside sur la même infrastructure physique que votre serveur. La règle 3-2-1 va plus loin : 3 copies des données, sur 2 supports différents, dont 1 hors site. Si le centre de données est affecté par une panne matérielle, une inondation ou une suppression accidentelle de votre compte, seule la copie hors site vous protège. Combinez les snapshots (réactivité) avec une sauvegarde déportée vers un stockage objet externe (Backblaze B2, S3, Scaleway…) pour couvrir les deux niveaux de risque.

Oui, c'est précisément l'avantage d'un dépôt Restic hébergé hors de votre VPS. Le dépôt vit sur le stockage objet externe (S3, Backblaze B2, Scaleway…) et n'a aucune dépendance vers votre serveur : vous pouvez y accéder depuis n'importe quelle machine disposant du binaire Restic, de la clé de chiffrement et des identifiants du dépôt. Conservez ces éléments dans un gestionnaire de secrets (Bitwarden, Vault…) indépendant de votre infrastructure, et testez une restauration sur une machine tierce au moins une fois par mois.