Sauvegardes

Les sauvegardes automatiques sont incluses à partir des offres d'hébergement intermédiaires, avec une fréquence qui augmente sur les offres supérieures. Sur VPS, rien n'est automatique : snapshots et sauvegardes se lancent à la demande depuis votre espace client, selon le plan et l'option Espace de sauvegarde. Le détail figure par offre sur les pages produits.

Non, il n'existe pas d'option de sauvegarde quotidienne premium. Sur l'hébergement mutualisé, la sauvegarde quotidienne est incluse dans l'offre Pro ; l'offre Business inclut une sauvegarde hebdomadaire.

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. Sur un VPS, en revanche, la restauration d'un snapshot porte sur le snapshot entier : elle remplace l'état actuel du serveur, sans extraction fichier par fichier. Les serveurs dédiés, eux, ne disposent ni de snapshot ni de sauvegarde fournis : la restauration d'un fichier passe par vos propres sauvegardes. Sur cPanel, cette granularité é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 à créer à la demande 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 à 95 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 vous planifiez déjà vos propres sauvegardes. Une sauvegarde ponctuelle prise juste avant la mise à jour vous permet de revenir à un état stable connu en quelques minutes en cas d'incompatibilité. Sur un VPS ServOrbit, aucune sauvegarde n'est planifiée automatiquement : créez un instantané depuis votre espace client juste avant la mise à jour ; les instantanés et sauvegardes inclus selon votre plan sont détaillés sur /tarifs.

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 :** des snapshots VPS à créer à la demande depuis l'espace client (à partir de l'offre VPS Power) et un espace de sauvegarde sur un stockage séparé (VPS Business ou en option). Rien n'est planifié automatiquement : la fréquence et la rétention ci-dessus s'automatisent de votre côté (cron, Restic, Borg). 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 les snapshots de votre VPS 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 sont disponibles selon le plan et se lancent à la demande depuis votre espace client.

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.

Sur l'hébergement mutualisé, la restauration se fait en libre-service : depuis votre espace client ServOrbit, ouvrez cPanel (« Accéder à cPanel »), puis le menu JetBackup ; choisissez la sauvegarde à la date souhaitée et l'élément à restaurer (compte complet, fichiers, base de données). Les sauvegardes disponibles dépendent de votre offre : hebdomadaires sur Business, quotidiennes sur Pro ; Start n'inclut pas de sauvegarde. En cas de difficulté, ouvrez un ticket de support en catégorie « Hébergement » en précisant la date de la sauvegarde et le chemin ou la base de données à restaurer.

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.

Dans cPanel, ouvrez JetBackup, choisissez « File Backups » et naviguez jusqu'au fichier concerné dans la liste des sauvegardes disponibles. Sélectionnez la date souhaitée, puis cliquez sur « Restore » à côté du fichier pour le restaurer seul, sans affecter le reste du compte. Si vous ne trouvez pas le fichier, contactez [email protected] avec le chemin et la date ciblés.

Sur l'hébergement mutualisé, la fréquence dépend de l'offre : Start n'inclut pas de sauvegarde, Business inclut une sauvegarde hebdomadaire et Pro une sauvegarde quotidienne. Les offres VPS disposent de politiques configurables selon votre contrat ; les serveurs dédiés, eux, ne comprennent aucune sauvegarde fournie. Consultez votre espace client ou écrivez à [email protected] pour connaître la politique exacte de votre offre.

Avant toute migration majeure de PostgreSQL, effectuez un dump complet avec `pg_dumpall -U postgres > backup_avant_migration.sql` pour la totalité du cluster, ou `pg_dump -U postgres -Fc nom_base > nom_base.dump` pour une base individuelle (format compressé, restaurable avec `pg_restore`). Vérifiez que le dump est complet et lisible avant de lancer la mise à jour. Pour restaurer, créez un cluster vierge avec la nouvelle version, puis importez avec `psql` ou `pg_restore`. Consultez notre article sur la migration PostgreSQL 18 pour les précautions spécifiques à cette version.

Pour une instance Odoo en production, une sauvegarde quotidienne complète de la base de données PostgreSQL est le minimum recommandé. Les entreprises avec un volume de transactions élevé ou une tolérance aux pertes de données faible privilégient des sauvegardes incrémentales toutes les 4 à 6 heures. Les fichiers du répertoire `filestore` (pièces jointes, documents) doivent être sauvegardés avec la même fréquence que la base pour garantir la cohérence. Il est également conseillé de conserver au moins 7 jours de sauvegardes quotidiennes et 4 semaines de sauvegardes hebdomadaires, stockées sur un emplacement distant ou un stockage objet séparé du VPS principal.

Avant tout déplacement, vérifiez que votre dernière sauvegarde complète (fichiers, bases de données, emails) est récente et testée. Sur nos hébergements, vous pouvez déclencher une sauvegarde manuelle depuis cPanel à tout moment. Sur un VPS, faites un snapshot si votre plan le permet, ou exportez vos volumes avant la migration. Conservez l'ancienne infrastructure active jusqu'à la validation du nouveau site et la fin de la propagation DNS — la fenêtre de bascule est ainsi réversible sans perte de données.

ServOrbit ne planifie aucune sauvegarde automatique de vos VPS : les instantanés (snapshots) et les sauvegardes se lancent à la demande depuis votre espace client, selon votre plan — instantanés à partir de l'offre VPS Power, sauvegardes avec l'espace de sauvegarde inclus sur VPS Business ou en option. La restauration d'un instantané ou d'une sauvegarde est disponible en libre-service depuis votre espace client en quelques clics. Pour une protection renforcée, il est recommandé de coupler ces outils avec une sauvegarde applicative externe planifiée de votre côté (ex. : Borg Backup ou Restic vers un stockage objet). Les instantanés résident sur le même stockage que le VPS ; seules les sauvegardes sont stockées sur un stockage séparé, pour résister à une défaillance matérielle.

La méthode recommandée est d'utiliser un script cron qui exécute `docker run --rm -v <volume>:/data -v /backup:/backup alpine tar czf /backup/<volume>-$(date +%F).tar.gz /data`, puis qui transfère l'archive vers un stockage distant (S3, SFTP). Des outils comme Restic ou Duplicati peuvent automatiser ce cycle avec chiffrement et rétention configurable. Vérifiez régulièrement la restauration : une sauvegarde non testée n'est pas une sauvegarde. Vous pouvez ouvrir un ticket support pour obtenir nos recommandations adaptées à votre stack.

La durée d'une restauration dépend du volume des données et du type de sauvegarde utilisé : une restauration JetBackup d'un compte cPanel léger (quelques centaines de Mo) prend généralement moins de 30 minutes depuis l'espace client, en libre-service. Pour les comptes plus volumineux ou les restaurations partielles (un seul fichier, une seule base de données), le délai est similaire. En cas de sinistre majeur nécessitant une intervention de notre équipe, ouvrez un ticket de priorité urgente depuis votre espace client en décrivant l'impact ; notre équipe prend en charge la demande dans les délais de notre SLA (99.9 % de disponibilité). Pour réduire au minimum le risque de perte de données, choisissez une offre dont la fréquence de sauvegarde vous convient : Business inclut une sauvegarde hebdomadaire, Pro une sauvegarde quotidienne.

Oui, votre VPS ServOrbit vous donne un accès root complet : vous pouvez installer rclone ou Restic et configurer des sauvegardes automatiques vers n'importe quel stockage objet compatible S3 (AWS S3, Backblaze B2, Wasabi…). Il est recommandé de planifier les sauvegardes via un timer systemd ou une crontab, de chiffrer les archives (Restic chiffre nativement), et de tester régulièrement une restauration complète. Sur les hébergements mutualisés, les sauvegardes passent par JetBackup, intégré à cPanel : celles qui sont incluses dépendent de l'offre (hebdomadaires sur Business, quotidiennes sur Pro, aucune sur Start), et vous les restaurez vous-même depuis le menu JetBackup de cPanel.

Dans l'interface Backrest, utilisez la fonction « Restore » en sélectionnant un snapshot récent et une cible temporaire (ex. `/tmp/restore-test`). Vérifiez ensuite que les fichiers clés sont présents et lisibles. Planifiez ce test mensuel en ajoutant une tâche automatisée dans Backrest ou un cron dédié — une sauvegarde non testée ne remplace pas une vraie politique de reprise.

Oui, Backrest permet de définir plusieurs dépôts (repos) dans sa configuration, chacun pointant vers un backend différent (S3, Backblaze B2, SFTP, local…). Vous pouvez ainsi répliquer vos sauvegardes vers deux buckets S3 distincts ou combiner un stockage local et un stockage objet distant. Chaque dépôt dispose de sa propre planification et de sa propre politique de rétention.

Non : les serveurs dédiés ServOrbit n'incluent ni sauvegarde automatique ni snapshot — le serveur physique n'offre pas ces fonctions, et la stratégie de sauvegarde vous revient (copies régulières vers un stockage externe indépendant). En cas de sinistre, la restauration se fait à partir de vos propres sauvegardes ; si le système doit être réinstallé, la demande se fait auprès de l'équipe support, et la réinstallation efface le disque. Pour toute question sur la stratégie à mettre en place, contactez [email protected].

Infisical chiffre ses secrets en base via une clé de chiffrement principale (`ENCRYPTION_KEY`) distincte des données PostgreSQL. La bonne pratique est de sauvegarder la base PostgreSQL (dump chiffré avec Restic ou pg_dump + gpg) et de stocker la `ENCRYPTION_KEY` séparément — dans un gestionnaire de secrets hors ligne ou un coffre-fort externe — jamais dans la même archive ni sur le même serveur. Ainsi, même si la sauvegarde de la base est compromise, les secrets restent illisibles sans la clé. Testez régulièrement la restauration complète (base + clé) dans un environnement isolé.

Connectez-vous à votre VPS en SSH et exécutez `mysqldump -u root -p nom_de_votre_base > sauvegarde.sql` pour exporter une base de données en un fichier SQL lisible. Pour automatiser cette sauvegarde, ajoutez la commande dans un cron job (`crontab -e`) et transférez le fichier vers un stockage distant (SFTP, S3 ou Backblaze B2) via `rsync` ou `rclone`. ServOrbit propose également des snapshots VPS à créer à la demande depuis votre espace client, en complément des sauvegardes applicatives.

La méthode recommandée est d'exécuter `pg_dump` via un timer systemd ou une tâche cron, puis d'envoyer l'archive chiffrée vers un stockage distant (S3-compatible, SFTP) avec un outil comme Restic ou Rclone. Pour un cycle minimal : une sauvegarde quotidienne conservée 7 jours et une hebdomadaire conservée 4 semaines. Vérifiez régulièrement la restauration sur un répertoire temporaire — une archive non testée n'est pas une sauvegarde. Notre équipe support peut vous orienter via votre espace client.

Avant la montée de version, faites un snapshot si votre plan le permet (VPS Power et VPS Business), puis une sauvegarde du panneau (comptes, sites, bases de données, boîtes mail) copiée HORS du serveur : un snapshot est stocké sur la même infrastructure. Gardez aussi une copie de la configuration du panneau et de vos tâches planifiées. Testez la restauration d'un site avant de lancer l'opération, et si la mise à niveau échoue, la réinstallation de l'OS depuis votre espace client efface le disque : sans cette copie externe, il n'y a rien à remettre.

Restaurez-la ailleurs que sur votre serveur en production : dans un répertoire temporaire ou sur un second VPS jetable. Vérifiez que les fichiers clés s'ouvrent, que la base de données redémarre avec ses données et que l'application répond, puis notez le temps total que cela a pris. Refaites ce test à intervalle régulier et après chaque changement important de votre configuration : seule une restauration réussie prouve que la sauvegarde sert à quelque chose.

La restauration d'un instantané remplace l'état entier du serveur : tout ce qui a été écrit après sa création (commandes, formulaires, fichiers envoyés) disparaît. Avant de restaurer, copiez ces données hors du VPS, par exemple un export de la base et une archive des dossiers modifiés, et prenez un nouvel instantané si votre plan en propose (VPS Power et VPS Business) afin de pouvoir revenir en arrière. Restaurez ensuite, puis réimportez les données récentes et vérifiez le site avant de le rouvrir au public.

Une sauvegarde saine remet le site propre, mais elle rétablit aussi la faille qui a permis l'intrusion : sans correction, le piratage peut se reproduire. Après la restauration, mettez à jour le cœur, les extensions et les thèmes, supprimez ceux qui ne servent plus, puis changez tous les mots de passe (administrateurs, base de données, accès FTP et SSH) et les clés de sécurité. Choisissez une sauvegarde antérieure à la première trace de compromission, pas simplement la plus récente, et gardez une copie de l'état infecté pour l'analyse.