Backup automatique offsite avec Restic ou BorgBackup

Il y a deux sortes d'administrateurs : ceux qui ont déjà perdu des données, et ceux qui vont en perdre. La question n'est pas si un disque, une mise à jour ratée, un rm -rf dans le mauvais dossier ou un ransomware vous frappera, mais quand, et ce que vous aurez sous la main à ce moment-là.

Ce guide met en place, en moins d'une heure, une sauvegarde automatique, chiffrée, incrémentale et hors-site de votre VPS avec l'un des deux meilleurs outils libres du domaine : Restic ou BorgBackup. Les deux sont excellents ; nous les comparons pour que vous choisissiez en connaissance de cause, puis nous détaillons chaque configuration de bout en bout, jusqu'au test de restauration, sans lequel une sauvegarde n'est qu'un espoir.

La règle 3-2-1 et ce que YorkHost fait déjà pour vous

La règle de référence : 3 copies de vos données, sur 2 supports différents, dont 1 hors-site.

Votre VPS YorkHost inclut déjà des sauvegardes quotidiennes conservées 7 jours glissants, restaurables en un clic depuis l'espace client. Sur la gamme VPS Ultimate, elles sont même stockées dans un autre datacenter. C'est une excellente première ligne de défense : le VPS est corrompu après une mise à jour du noyau, vous revenez à la veille en quelques minutes.

Mais ces snapshots ont trois limites, communes à tous les hébergeurs :

Granularité : c'est le disque entier ou rien. Récupérer un seul fichier effacé demande de restaurer tout le VPS ailleurs.
Rétention : 7 jours. Une corruption silencieuse découverte trois semaines plus tard n'est plus récupérable.
Cohérence applicative : un snapshot de disque pris pendant une écriture MariaDB ou PostgreSQL n'est pas garanti cohérent. Il faut un dump propre.

La sauvegarde applicative de ce guide comble exactement ces trois points. Les deux mécanismes se complètent : le snapshot pour le désastre système, Restic ou Borg pour les données.

Restic ou Borg ?

	Restic	BorgBackup
Langage, binaire	Go, un seul binaire statique	Python + C, paquet à installer
Destinations	SFTP, S3, Backblaze B2, Azure, Google Cloud, rest-server, local, rclone (tout)	SSH (avec Borg installé côté serveur), local
Chiffrement	Toujours actif, AES-256	Optionnel, AES-256 ou ChaCha20, `repokey`/`keyfile`
Déduplication	Oui, par blocs de taille variable	Oui, par blocs de taille variable
Compression	Oui (auto, zstd) depuis la v0.14	Oui, lz4/zstd/zlib/lzma au choix
Vitesse	Bonne, un peu plus gourmande en RAM et en requêtes	Excellente sur SSH, très économe
Protection ransomware	Dépend du backend (`append-only` avec rest-server, verrouillage objet S3)	Mode `--append-only` natif côté serveur SSH
Accès concurrent	Plusieurs clients sur un même dépôt	Un client à la fois par dépôt
Montage du dépôt	`restic mount`	`borg mount`

En résumé :

Choisissez Restic si vous voulez sauvegarder vers un stockage objet (S3, B2) ou plusieurs types de destinations, ou si plusieurs serveurs doivent partager un même dépôt.
Choisissez Borg si votre destination est un serveur accessible en SSH (comme un VPS Storage), et que vous voulez la solution la plus rapide et la plus économe, avec le mode append-only le plus simple à mettre en place.

Les deux sont matures (plus de dix ans pour Borg), activement maintenus, et utilisés en production par des milliers d'organisations. Vous ne ferez pas le mauvais choix.

Où envoyer les sauvegardes ?

« Hors-site » signifie : sur une machine qui ne partage ni le disque, ni l'hyperviseur, ni idéalement le datacenter de votre VPS. Trois options courantes :

Destination	Avantages	Points d'attention
VPS Storage YorkHost (500 Go ou 1 To SSD)	Accès SSH/SFTP natif, Borg ou Restic sans intermédiaire, réseau rapide, Anti-DDoS inclus, tarif fixe sans facturation à la requête	Même hébergeur : parfait contre la perte du VPS, à compléter par un second dépôt ailleurs si vous voulez survivre à la perte d'un fournisseur entier
Stockage objet S3 compatible (Backblaze B2, Scaleway, Wasabi…)	Très bon marché au To, durable, verrouillage objet possible	Restic uniquement, coûts de requêtes et de sortie à surveiller
Machine chez vous (NAS, Raspberry Pi)	Vous détenez physiquement les données	Connexion domestique lente, IP dynamique, machine à maintenir

Ce guide utilise un VPS Storage YorkHost comme destination principale, avec l'IP fictive 203.0.113.200. Les commandes sont identiques pour n'importe quel serveur SSH.

Étape 1 : Préparer le serveur de stockage

Sur le VPS Storage, créez un utilisateur dédié aux sauvegardes, sans shell interactif, et un répertoire pour les dépôts :

sudo adduser --disabled-password --gecos "" backup
sudo mkdir -p /srv/backups
sudo chown backup:backup /srv/backups
sudo chmod 700 /srv/backups

Sur le VPS à sauvegarder, générez une clé SSH dédiée (sans passphrase, puisqu'elle sera utilisée par un timer sans intervention humaine) :

sudo ssh-keygen -t ed25519 -f /root/.ssh/backup_ed25519 -N "" -C "backup@$(hostname)"
sudo cat /root/.ssh/backup_ed25519.pub

Sur le VPS Storage, autorisez cette clé pour l'utilisateur backup :

sudo mkdir -p /home/backup/.ssh
sudo nano /home/backup/.ssh/authorized_keys
# collez la clé publique
sudo chown -R backup:backup /home/backup/.ssh
sudo chmod 700 /home/backup/.ssh && sudo chmod 600 /home/backup/.ssh/authorized_keys

Testez depuis le VPS source :

sudo ssh -i /root/.ssh/backup_ed25519 backup@203.0.113.200 "echo OK"

Pour simplifier toutes les commandes qui suivent, déclarez l'hôte dans /root/.ssh/config :

Host storage
    HostName 203.0.113.200
    User backup
    IdentityFile /root/.ssh/backup_ed25519
    IdentitiesOnly yes

Sécurisez aussi le serveur de stockage

Le VPS Storage contient une copie de toutes vos données ; il mérite le même soin que la source : SSH par clé uniquement, UFW n'autorisant le port 22 que depuis les IP de vos VPS sources, mises à jour automatiques.

Étape 2 : Décider quoi sauvegarder

Sauvegarder tout le disque est tentant mais inefficace : le système se réinstalle en dix minutes, ce sont vos données et votre configuration qui sont irremplaçables. Une liste typique :

À sauvegarder	Pourquoi
`/etc`	Toute la configuration système (Nginx, SSH, cron, firewall…)
`/home` et `/root`	Fichiers utilisateurs, scripts, clés
`/var/www`	Sites et applications web
`/opt`	Applications installées manuellement, stacks Docker
`/var/lib/docker/volumes`	Données des conteneurs (à condition qu'elles ne contiennent pas de base de données active)
`/var/backups/db`	Les dumps de bases de données produits juste avant (voir ci-dessous)

À exclure : /proc, /sys, /dev, /run, /tmp, les caches (/var/cache, ~/.cache, node_modules), et les fichiers de données bruts des bases (/var/lib/mysql, /var/lib/postgresql) qui seraient incohérents.

Les bases de données : un dump avant chaque sauvegarde

Créez un script qui exporte proprement chaque base ; il sera appelé au début de chaque sauvegarde :

sudo mkdir -p /var/backups/db
sudo nano /usr/local/bin/dump-databases.sh

#!/bin/bash
set -euo pipefail
DEST=/var/backups/db
mkdir -p "$DEST"

# MariaDB / MySQL (si installé) : le compte root Unix se connecte sans mot de passe
if command -v mariadb-dump >/dev/null 2>&1; then
  mariadb-dump --all-databases --single-transaction --routines --events \
    | gzip -6 > "$DEST/mariadb-all.sql.gz"
elif command -v mysqldump >/dev/null 2>&1; then
  mysqldump --all-databases --single-transaction --routines --events \
    | gzip -6 > "$DEST/mysql-all.sql.gz"
fi

# PostgreSQL (si installé)
if command -v pg_dumpall >/dev/null 2>&1; then
  sudo -u postgres pg_dumpall | gzip -6 > "$DEST/postgresql-all.sql.gz"
fi

chmod 600 "$DEST"/*.gz

sudo chmod +x /usr/local/bin/dump-databases.sh
sudo /usr/local/bin/dump-databases.sh && ls -lh /var/backups/db

Pour PostgreSQL en production, préférez un dump par base au format custom comme décrit dans Installer PostgreSQL production-ready, plus souple à restaurer.

Option A : Restic

Installation

Debian et Ubuntu fournissent Restic, mais souvent dans une version datée. Le binaire officiel est un simple fichier :

sudo apt install -y restic
restic version

Si la version des dépôts est trop ancienne (vérifiez sur github.com/restic/restic/releases), installez le binaire officiel par-dessus :

RESTIC_VER=0.18.1   # remplacez par la dernière version stable
wget -q "https://github.com/restic/restic/releases/download/v${RESTIC_VER}/restic_${RESTIC_VER}_linux_amd64.bz2"
bunzip2 "restic_${RESTIC_VER}_linux_amd64.bz2"
sudo install -m 755 "restic_${RESTIC_VER}_linux_amd64" /usr/local/bin/restic
restic version

Initialiser le dépôt

Restic chiffre toujours. Le mot de passe du dépôt est la seule chose qui permette de lire vos sauvegardes : générez-le fort, stockez-le dans un fichier protégé et dans votre gestionnaire de mots de passe.

sudo mkdir -p /etc/restic
openssl rand -base64 32 | sudo tee /etc/restic/password > /dev/null
sudo chmod 600 /etc/restic/password

Créez un fichier d'environnement pour ne pas répéter les paramètres :

sudo nano /etc/restic/env

export RESTIC_REPOSITORY="sftp:storage:/srv/backups/$(hostname)-restic"
export RESTIC_PASSWORD_FILE="/etc/restic/password"
export RESTIC_COMPRESSION="auto"

sudo chmod 600 /etc/restic/env
source /etc/restic/env
sudo -E restic init

Pour une destination S3 à la place, le dépôt s'écrit s3:s3.eu-west-3.amazonaws.com/mon-bucket/restic et vous ajoutez AWS_ACCESS_KEY_ID et AWS_SECRET_ACCESS_KEY dans le fichier d'environnement. Rien d'autre ne change.

Les exclusions

sudo nano /etc/restic/excludes.txt

/proc
/sys
/dev
/run
/tmp
/var/tmp
/var/cache
/var/lib/mysql
/var/lib/postgresql
/var/lib/docker/overlay2
/var/lib/docker/image
**/node_modules
**/.cache
**/*.log
/root/.cache
/home/*/.cache

Le script de sauvegarde

sudo nano /usr/local/bin/restic-backup.sh

#!/bin/bash
set -euo pipefail
source /etc/restic/env

echo "== Dump des bases de données"
/usr/local/bin/dump-databases.sh

echo "== Sauvegarde"
restic backup \
  /etc /root /home /var/www /opt /var/backups/db /var/lib/docker/volumes \
  --exclude-file=/etc/restic/excludes.txt \
  --exclude-caches \
  --one-file-system \
  --tag auto

echo "== Rétention"
restic forget \
  --keep-daily 14 \
  --keep-weekly 8 \
  --keep-monthly 12 \
  --keep-yearly 2 \
  --prune

echo "== Vérification rapide"
restic check --read-data-subset=5%

echo "Sauvegarde terminée : $(date)"

sudo chmod 700 /usr/local/bin/restic-backup.sh
sudo /usr/local/bin/restic-backup.sh

La première exécution envoie tout ; les suivantes ne transfèrent que les blocs nouveaux ou modifiés, généralement quelques Mo par jour. --read-data-subset=5% relit 5 % des données réelles à chaque passage : sur vingt jours, l'intégralité du dépôt est vérifiée sans surcharger le réseau.

Consulter et restaurer

source /etc/restic/env

# Lister les snapshots
restic snapshots

# Voir ce qu'un snapshot contient
restic ls latest /var/www

# Restaurer un fichier ou un dossier précis dans /tmp/restore
restic restore latest --target /tmp/restore --include /var/www/monsite.fr/wp-config.php

# Restaurer tout un snapshot à sa place d'origine (attention : écrase)
restic restore a1b2c3d4 --target /

# Explorer le dépôt comme un système de fichiers
mkdir -p /mnt/restic && restic mount /mnt/restic
# puis dans un autre terminal : ls /mnt/restic/snapshots/latest/

restic mount est la fonction la plus agréable au quotidien : vous naviguez dans chaque snapshot comme dans un dossier et copiez ce dont vous avez besoin.

Protection contre les ransomwares avec rest-server

Si un attaquant obtient root sur votre VPS, il obtient aussi la clé SSH et le mot de passe du dépôt, et peut donc supprimer les sauvegardes. Contre cela, la destination doit refuser les suppressions. Avec un serveur SSH classique, Restic ne peut pas l'imposer ; la solution est rest-server, le serveur HTTP officiel de Restic, lancé en mode --append-only sur le VPS Storage :

# Sur le VPS Storage
wget https://github.com/restic/rest-server/releases/latest/download/rest-server_linux_amd64.tar.gz
tar -xzf rest-server_linux_amd64.tar.gz && sudo install rest-server*/rest-server /usr/local/bin/
sudo useradd -r -s /usr/sbin/nologin restic
sudo mkdir -p /srv/restic && sudo chown restic:restic /srv/restic

# /etc/systemd/system/rest-server.service
[Unit]
Description=Restic REST Server
After=network.target

[Service]
User=restic
ExecStart=/usr/local/bin/rest-server --path /srv/restic --append-only --private-repos --htpasswd-file /srv/restic/.htpasswd --listen 127.0.0.1:8000
Restart=always

[Install]
WantedBy=multi-user.target

Créez les identifiants avec htpasswd -B -c /srv/restic/.htpasswd vps1, exposez le port 8000 derrière un reverse proxy Nginx en HTTPS limité aux IP de vos VPS, puis utilisez RESTIC_REPOSITORY="rest:https://vps1:motdepasse@backup.example.com/vps1". En mode append-only, restic forget --prune doit être lancé depuis le serveur de stockage (avec restic -r /srv/restic/vps1), jamais depuis le client.

Option B : BorgBackup

Installation

Borg doit être installé sur les deux machines : le VPS source et le VPS Storage (le serveur exécute borg serve à chaque connexion).

# Sur les deux machines
sudo apt install -y borgbackup
borg --version

Debian 12 fournit Borg 1.2, Debian 13 fournit Borg 1.4. Les deux machines doivent avoir des versions compatibles (même version majeure).

Initialiser le dépôt

sudo mkdir -p /etc/borg
openssl rand -base64 32 | sudo tee /etc/borg/passphrase > /dev/null
sudo chmod 600 /etc/borg/passphrase

sudo nano /etc/borg/env

export BORG_REPO="ssh://storage/srv/backups/$(hostname)-borg"
export BORG_PASSCOMMAND="cat /etc/borg/passphrase"
export BORG_RSH="ssh -i /root/.ssh/backup_ed25519 -o IdentitiesOnly=yes"

sudo chmod 600 /etc/borg/env
source /etc/borg/env
sudo -E borg init --encryption=repokey-blake2

Le mode repokey stocke la clé de chiffrement (elle-même protégée par la passphrase) dans le dépôt. Exportez-la et conservez-la ailleurs : sans elle, même avec la passphrase, le dépôt est illisible.

sudo -E borg key export "$BORG_REPO" /root/borg-key-$(hostname).txt
# Copiez ce fichier dans votre gestionnaire de mots de passe, puis supprimez-le du VPS

Le script de sauvegarde

sudo nano /usr/local/bin/borg-backup.sh

#!/bin/bash
set -euo pipefail
source /etc/borg/env

echo "== Dump des bases de données"
/usr/local/bin/dump-databases.sh

echo "== Sauvegarde"
borg create \
  --verbose --stats --show-rc \
  --compression zstd,3 \
  --one-file-system \
  --exclude-caches \
  --exclude '/proc' --exclude '/sys' --exclude '/dev' --exclude '/run' \
  --exclude '/tmp' --exclude '/var/tmp' --exclude '/var/cache' \
  --exclude '/var/lib/mysql' --exclude '/var/lib/postgresql' \
  --exclude '/var/lib/docker/overlay2' --exclude '/var/lib/docker/image' \
  --exclude '*/node_modules' --exclude '*/.cache' --exclude '*.log' \
  ::'{hostname}-{now:%Y-%m-%d_%H%M}' \
  /etc /root /home /var/www /opt /var/backups/db /var/lib/docker/volumes

echo "== Rétention"
borg prune \
  --list --show-rc \
  --keep-daily 14 \
  --keep-weekly 8 \
  --keep-monthly 12 \
  --keep-yearly 2

echo "== Compactage"
borg compact

echo "Sauvegarde terminée : $(date)"

sudo chmod 700 /usr/local/bin/borg-backup.sh
sudo /usr/local/bin/borg-backup.sh

Depuis Borg 1.2, prune ne libère plus l'espace lui-même : compact est indispensable, sinon le dépôt ne fait que grossir.

Ajoutez une vérification complète une fois par semaine (elle peut être longue sur un gros dépôt) :

sudo -E borg check --verify-data

Consulter et restaurer

source /etc/borg/env

# Lister les archives
borg list

# Contenu d'une archive
borg list ::vps1-2026-09-08_0300 /var/www

# Restaurer un fichier précis dans le dossier courant (Borg restaure en relatif)
cd /tmp && mkdir restore && cd restore
borg extract ::vps1-2026-09-08_0300 var/www/monsite.fr/wp-config.php

# Tout restaurer (depuis / pour retrouver les chemins d'origine)
cd / && borg extract ::vps1-2026-09-08_0300

# Monter le dépôt entier
mkdir -p /mnt/borg && borg mount :: /mnt/borg
ls /mnt/borg/
borg umount /mnt/borg

Protection contre les ransomwares : le mode append-only

C'est l'un des grands atouts de Borg, et il tient en une ligne. Sur le VPS Storage, modifiez la ligne de la clé dans /home/backup/.ssh/authorized_keys pour forcer la commande exécutée :

command="borg serve --append-only --restrict-to-path /srv/backups/vps1-borg",restrict ssh-ed25519 AAAA... backup@vps1

Désormais, le VPS source peut ajouter des archives mais ne peut rien effacer réellement : un borg prune ou borg delete lancé depuis le client semble réussir, mais les données restent dans le dépôt et l'opération peut être annulée côté serveur en revenant à une transaction antérieure (voir la section append-only mode de la documentation Borg). Un attaquant qui compromet le VPS ne peut donc pas détruire votre historique.

La rétention se fait alors depuis le serveur de stockage, par exemple chaque dimanche, avec un accès direct au dépôt :

# Sur le VPS Storage, en tant que backup
export BORG_PASSCOMMAND="cat /home/backup/.passphrase-vps1"
borg prune --keep-daily 14 --keep-weekly 8 --keep-monthly 12 /srv/backups/vps1-borg
borg compact /srv/backups/vps1-borg

Retirez simplement --append-only du command= pendant une opération exceptionnelle si nécessaire.

Étape 3 : Automatiser avec un timer systemd

Un timer systemd est plus fiable qu'un cron pour cette tâche : les logs vont dans journalctl, une exécution manquée (VPS éteint à l'heure prévue) est rattrapée au démarrage, et deux sauvegardes ne se chevauchent jamais.

sudo nano /etc/systemd/system/backup.service

[Unit]
Description=Sauvegarde hors-site (Restic ou Borg)
After=network-online.target
Wants=network-online.target

[Service]
Type=oneshot
# Choisissez l'un des deux scripts
ExecStart=/usr/local/bin/restic-backup.sh
#ExecStart=/usr/local/bin/borg-backup.sh
Nice=10
IOSchedulingClass=idle

sudo nano /etc/systemd/system/backup.timer

[Unit]
Description=Sauvegarde hors-site quotidienne

[Timer]
OnCalendar=*-*-* 03:00:00
RandomizedDelaySec=15min
Persistent=true

[Install]
WantedBy=timers.target

sudo systemctl daemon-reload
sudo systemctl enable --now backup.timer
systemctl list-timers backup.timer

Nice=10 et IOSchedulingClass=idle garantissent que la sauvegarde cède la priorité à vos applications si elle tombe pendant un pic de trafic. RandomizedDelaySec évite que tous vos VPS frappent le serveur de stockage à la même seconde.

Pour lancer une sauvegarde à la main et suivre son journal :

sudo systemctl start backup.service
sudo journalctl -u backup.service -f

Étape 4 : Être prévenu quand ça échoue

Une sauvegarde qui échoue silencieusement pendant trois mois est pire que pas de sauvegarde du tout : vous croyez être protégé. Ajoutez une notification en cas d'échec avec un service déclenché par OnFailure :

sudo nano /etc/systemd/system/backup-notify.service

[Unit]
Description=Notification d'échec de sauvegarde

[Service]
Type=oneshot
ExecStart=/usr/local/bin/notify-backup-failed.sh

sudo nano /usr/local/bin/notify-backup-failed.sh

#!/bin/bash
# Discord : créez un webhook dans les paramètres du salon
WEBHOOK="https://discord.com/api/webhooks/xxxx/yyyy"
LOGS=$(journalctl -u backup.service -n 15 --no-pager | tail -c 1500)
curl -s -H "Content-Type: application/json" \
  -d "{\"content\": \"❌ **Sauvegarde échouée sur $(hostname)**\n\`\`\`\n${LOGS}\n\`\`\`\"}" \
  "$WEBHOOK"

sudo chmod 700 /usr/local/bin/notify-backup-failed.sh

Et dans backup.service, section [Unit] :

OnFailure=backup-notify.service

sudo systemctl daemon-reload

Pensez aussi au problème inverse : un timer qui ne se déclenche plus (service désactivé par erreur, VPS réinstallé) ne produit aucune erreur. Un service de « dead man's switch » comme Healthchecks.io (gratuit pour quelques contrôles) vous alerte si un ping attendu n'arrive pas : ajoutez curl -fsS -m 10 https://hc-ping.com/votre-uuid à la fin du script de sauvegarde.

Étape 5 : Tester la restauration (vraiment)

C'est l'étape que tout le monde saute, et c'est la seule qui compte. Une fois par trimestre, ou après tout changement de configuration :

Commandez un VPS d'essai ou utilisez une VM locale.
Installez Restic ou Borg, copiez le fichier de mot de passe (et la clé exportée pour Borg).
Restaurez le dernier snapshot complet.
Réimportez le dump de base de données : gunzip < /var/backups/db/mariadb-all.sql.gz | mysql.
Démarrez l'application et vérifiez qu'elle fonctionne.
Notez le temps que cela vous a pris : c'est votre RTO réel, celui que vous annoncerez en cas de sinistre.

Si l'un de ces points coince, vous venez de découvrir un problème le bon jour, celui où rien n'est en feu.

Checklist

Dépannage

`Fatal: unable to open repository` / `Repository does not exist`

Le chemin du dépôt est faux ou la connexion SSH échoue. Testez ssh storage "ls -la /srv/backups". Pour Borg, vérifiez que borgbackup est bien installé côté serveur : ssh storage "borg --version".

`repository is already locked` (Borg) / `unable to create lock` (Restic)

Une sauvegarde précédente a été interrompue. Vérifiez qu'aucun processus ne tourne (pgrep -a borg ou pgrep -a restic), puis borg break-lock :: ou restic unlock.

La sauvegarde est lente

La première l'est toujours (tout est envoyé). Ensuite, vérifiez la compression (zstd plutôt que lzma), et surtout les exclusions : des logs volumineux ou un cache qui change à chaque exécution cassent la déduplication. restic backup --dry-run -v ou borg create --dry-run --list montrent ce qui est envoyé.

Le dépôt grossit sans fin

Restic : forget sans --prune ne libère rien. Borg : prune sans compact non plus. Vérifiez aussi qu'aucune sauvegarde n'inclut le dossier des dumps et les fichiers bruts de la base.

`borg: error: unrecognized arguments` ou incompatibilité de version

Client et serveur ont des versions majeures différentes. Alignez-les (installez la même version des deux côtés, éventuellement via pip install borgbackup==1.4.*).

Restauration : les permissions ou propriétaires sont faux

Restic et Borg restaurent les métadonnées si l'extraction est lancée en root. Avec un autre utilisateur, les fichiers appartiennent à cet utilisateur.

Un stockage hors-site fait pour ça

Le VPS Storage YorkHost (500 Go ou 1 To de SSD Enterprise) est la destination naturelle pour Borg ou Restic : accès SSH complet pour borg serve ou rest-server, réseau 1 à 10 Gbps vers vos autres VPS, Anti-DDoS Stormwall & Gcore inclus, tarif mensuel fixe sans frais de requête ni de sortie, et sans engagement. Combiné aux sauvegardes 7 jours glissants incluses avec chaque VPS Linux, vous obtenez une vraie stratégie 3-2-1 pour quelques euros par mois.

La règle 3-2-1 et ce que YorkHost fait déjà pour vous​

Restic ou Borg ?​

Où envoyer les sauvegardes ?​

Étape 1 : Préparer le serveur de stockage​

Étape 2 : Décider quoi sauvegarder​

Les bases de données : un dump avant chaque sauvegarde​

Option A : Restic​

Installation​

Initialiser le dépôt​

Les exclusions​

Le script de sauvegarde​

Consulter et restaurer​

Protection contre les ransomwares avec rest-server​

Option B : BorgBackup​

Installation​

Initialiser le dépôt​

Le script de sauvegarde​

Consulter et restaurer​

Protection contre les ransomwares : le mode append-only​

Étape 3 : Automatiser avec un timer systemd​

Étape 4 : Être prévenu quand ça échoue​

Étape 5 : Tester la restauration (vraiment)​

Checklist​

Dépannage​

Fatal: unable to open repository / Repository does not exist​

repository is already locked (Borg) / unable to create lock (Restic)​

La sauvegarde est lente​

Le dépôt grossit sans fin​

borg: error: unrecognized arguments ou incompatibilité de version​

Restauration : les permissions ou propriétaires sont faux​

La règle 3-2-1 et ce que YorkHost fait déjà pour vous

Restic ou Borg ?

Où envoyer les sauvegardes ?

Étape 1 : Préparer le serveur de stockage

Étape 2 : Décider quoi sauvegarder

Les bases de données : un dump avant chaque sauvegarde

Option A : Restic

Installation

Initialiser le dépôt

Les exclusions

Le script de sauvegarde

Consulter et restaurer

Protection contre les ransomwares avec rest-server

Option B : BorgBackup

Installation

Initialiser le dépôt

Le script de sauvegarde

Consulter et restaurer

Protection contre les ransomwares : le mode append-only

Étape 3 : Automatiser avec un timer systemd

Étape 4 : Être prévenu quand ça échoue

Étape 5 : Tester la restauration (vraiment)

Checklist

Dépannage

`Fatal: unable to open repository` / `Repository does not exist`

`repository is already locked` (Borg) / `unable to create lock` (Restic)

La sauvegarde est lente

Le dépôt grossit sans fin

`borg: error: unrecognized arguments` ou incompatibilité de version

Restauration : les permissions ou propriétaires sont faux