Sauvegarde hors site et replication avec Plakar

13 min de lecture·Matthieu·caddydebiansystemds3ubuntuplakaroffsite-backupbackupreplication|

Repliquez vos snapshots plakar vers un serveur distant en HTTPS ou vers un stockage objet compatible S3. Automatisez les sauvegardes et la synchronisation hors site avec le planificateur integre de plakar sous forme de service systemd sur Debian 12 ou Ubuntu 24.04.

Pourquoi avez-vous besoin de sauvegardes hors site ?

Les sauvegardes locales protegent contre la suppression accidentelle et la corruption de fichiers. Elles ne protegent pas contre la panne de disque, les rancongiciels ou un serveur compromis. Si vos sauvegardes se trouvent sur la meme machine que les donnees, un seul incident detruit les deux. La regle 3-2-1 dit : trois copies, deux supports differents, une copie hors site. Ce guide couvre la partie hors site.

Cet article fait suite a Sauvegarder votre VPS Linux avec Plakar. Vous devriez deja avoir plakar installe sur un VPS Debian 12 ou Ubuntu 24.04, un depot Kloset local dans /var/backups/plakar et au moins un snapshot. Si ce n'est pas le cas, commencez par ce guide.

Deux options hors site sont integrees a plakar. Le chemin A replique les snapshots vers un second serveur executant plakar server en HTTPS. Le chemin B envoie les snapshots vers un stockage objet compatible S3. Les deux utilisent plakar sync et conservent le chiffrement Kloset de bout en bout. Choisissez un chemin ou les deux. La section automatisation a la fin s'applique aux deux.

Comment repliquer les snapshots plakar vers un serveur distant ?

Lancez plakar server sur un second VPS pour exposer un depot Kloset en HTTP. Placez Caddy en amont pour le TLS automatique. Depuis la machine source, compilez le plugin d'integration HTTP, ajoutez le serveur distant comme depot nomme et envoyez les snapshots avec plakar sync to. Les donnees restent chiffrees au repos dans le depot Kloset et en transit via HTTPS. Cette approche vous donne le controle total des deux points de terminaison.

Vous avez besoin de deux machines pour cette section. VM1 est le serveur de production avec vos sauvegardes plakar existantes. VM2 est le serveur de sauvegarde distant dans un autre centre de donnees ou chez un autre fournisseur. VM2 a besoin d'un nom de domaine pointant vers son adresse IP pour les certificats TLS. Les exemples utilisent backup.example.com comme domaine.

Toutes les commandes de ce guide s'executent en root. Si vous utilisez un utilisateur sudo, ajoutez sudo devant chaque commande.

Comment configurer plakar server sur VM2 ?

Installez plakar sur VM2 en suivant les memes etapes que l'article principal :

apt update
apt install -y curl gnupg2
curl -fsSL https://plakar.io/dist/keys/community-v1.1.0.gpg | gpg --dearmor -o /usr/share/keyrings/plakar.gpg
echo "deb [signed-by=/usr/share/keyrings/plakar.gpg] https://plakar.io/dist/repos/deb/ stable main" | tee /etc/apt/sources.list.d/plakar.list
apt update
apt install -y plakar

plakar version

plakar/v1.0.6

Creez un depot Kloset sur VM2. Generez une phrase de passe robuste et enregistrez-la dans un gestionnaire de mots de passe. C'est un depot different de celui de VM1, il a donc sa propre phrase de passe :

mkdir -p /var/backups/plakar
openssl rand -base64 32

Conservez la sortie. Vous aurez besoin de cette phrase de passe sur VM2 et VM1. Creez le depot :

plakar at /var/backups/plakar create

repository passphrase:

Entrez la phrase de passe generee. Restreignez les permissions du repertoire du depot :

chmod 700 /var/backups/plakar

Enregistrez la phrase de passe dans un fichier pour que plakar server demarre sans invite interactive :

mkdir -p /etc/plakar
cat > /etc/plakar/passphrase <<'EOF'
YOUR_GENERATED_PASSPHRASE_HERE
EOF
chmod 600 /etc/plakar/passphrase
chown root:root /etc/plakar/passphrase
ls -la /etc/plakar/passphrase

-rw-------  1 root root 45 Mar 20 14:00 /etc/plakar/passphrase

Enregistrez le depot par nom :

plakar store add backups \
  location=/var/backups/plakar \
  passphrase_cmd="cat /etc/plakar/passphrase"

Demarrez plakar server pour exposer le depot en HTTP. Liez-le a localhost uniquement. Caddy gerera les connexions externes :

plakar at @backups server -listen 127.0.0.1:9876

Le serveur tourne au premier plan et journalise les requetes sur stdout. Laissez ce terminal ouvert. Vous configurerez un service systemd plus tard.

Par defaut, plakar server desactive les operations de suppression. Cela empeche les clients distants de retirer des snapshots. Pour la synchronisation, l'acces en ecriture suffit. Gardez les suppressions desactivees sauf raison particuliere.

Comment placer Caddy en amont de plakar server pour le TLS ?

Caddy fournit le HTTPS automatique avec les certificats Let's Encrypt. Il termine le TLS et transmet les requetes a plakar server sur localhost. Les clients externes se connectent sur le port 443, et Caddy redirige vers le port 9876.

Avant d'installer Caddy, verifiez que l'enregistrement DNS A pour backup.example.com pointe vers l'adresse IP de VM2. Caddy en a besoin pour obtenir un certificat TLS via le challenge ACME HTTP-01. Le port 80 doit egalement etre ouvert pour le challenge.

Installez Caddy sur VM2 :

apt install -y debian-keyring debian-archive-keyring apt-transport-https curl
curl -1sLf 'https://dl.cloudsmith.io/public/caddy/stable/gpg.key' | gpg --dearmor -o /usr/share/keyrings/caddy-stable-archive-keyring.gpg
curl -1sLf 'https://dl.cloudsmith.io/public/caddy/stable/debian.deb.txt' | tee /etc/apt/sources.list.d/caddy-stable.list
apt update
apt install -y caddy

Remplacez le Caddyfile par defaut par une configuration de reverse proxy. Remplacez backup.example.com par votre domaine reel :

cat > /etc/caddy/Caddyfile <<'EOF'
backup.example.com {
    reverse_proxy 127.0.0.1:9876
}
EOF

Rechargez Caddy pour appliquer la configuration :

systemctl reload caddy
systemctl status caddy

● caddy.service - Caddy
     Loaded: loaded (/lib/systemd/system/caddy.service; enabled; preset: enabled)
     Active: active (running)

Caddy obtient le certificat TLS automatiquement a la premiere requete. Testez depuis VM1 ou n'importe quelle machine externe :

curl -I https://backup.example.com

Une reponse 200 ou 404 signifie que Caddy transmet correctement au serveur plakar. Une erreur TLS signifie que le certificat n'est pas encore pret.

Comment securiser le serveur plakar avec des regles de pare-feu ?

Ouvrez les ports 80 (challenge ACME) et 443 (HTTPS). Le port 9876 reste lie a 127.0.0.1 et n'est donc pas accessible depuis l'exterieur meme sans regle de blocage explicite. Pour une configuration detaillee du pare-feu, consultez Comment configurer un pare-feu Linux avec UFW et nftables sur un VPS.

Avec UFW :

ufw allow 80/tcp
ufw allow 443/tcp
ufw status

Avec nftables, ajoutez a votre jeu de regles :

nft add rule inet filter input tcp dport 80 accept
nft add rule inet filter input tcp dport 443 accept

Apres l'emission du certificat, vous pouvez fermer le port 80 si vous configurez Caddy pour utiliser le challenge TLS-ALPN-01 a la place. Le challenge HTTP-01 par defaut necessite que le port 80 reste ouvert pour les renouvellements.

Comment executer plakar server comme service systemd sur VM2 ?

Creez une unite systemd pour que plakar server demarre au boot et redemarre en cas d'echec :

cat > /etc/systemd/system/plakar-server.service <<EOF
[Unit]
Description=Plakar Backup Server
After=network.target

[Service]
Type=simple
ExecStart=/usr/bin/plakar at @backups server -listen 127.0.0.1:9876
Restart=on-failure
RestartSec=10
User=root
StandardOutput=journal
StandardError=journal

[Install]
WantedBy=multi-user.target
EOF

Arretez le serveur en premier plan s'il tourne encore (Ctrl+C dans ce terminal), puis activez le service systemd. enable --now le fait survivre aux redemarrages et le demarre immediatement :

systemctl daemon-reload
systemctl enable --now plakar-server.service
systemctl status plakar-server.service

● plakar-server.service - Plakar Backup Server
     Loaded: loaded (/etc/systemd/system/plakar-server.service; enabled; preset: enabled)
     Active: active (running)

Surveillez les journaux du serveur :

journalctl -u plakar-server.service -f

Comment installer l'integration HTTP sur VM1 ?

Retour sur VM1. Plakar a besoin de l'integration HTTP pour se connecter aux depots distants. Le backend HTTP est un plugin livre separement du paquet principal. Compilez-le depuis les sources en utilisant la recette du serveur de plugins plakar. Cela necessite Go et Make :

apt install -y golang-go make

Telechargez le fichier recette et compilez le plugin :

curl -fsSL https://plugins.plakar.io/kloset/recipe/v1.0.0/http.yaml -o /tmp/http.yaml
plakar pkg build /tmp/http.yaml

La compilation cree l'integration HTTP depuis son depot source et produit une archive .ptar dans le repertoire courant. Installez le plugin compile :

plakar pkg add ./http_v1.0.5_linux_amd64.ptar

Le nom de fichier exact depend de la version et de l'architecture. Verifiez ce que pkg build a produit avec ls *.ptar. Listez les plugins installes pour confirmer :

plakar pkg list

http@v1.0.5

Comment synchroniser les snapshots de VM1 vers le serveur distant ?

Enregistrez le serveur distant comme depot nomme. Remplacez backup.example.com par votre domaine. Le passphrase_cmd doit retourner la phrase de passe du depot de VM2, pas celle de VM1. Copiez la phrase de passe de VM2 dans un fichier separe sur VM1 :

cat > /etc/plakar/remote-passphrase <<'EOF'
VM2_STORE_PASSPHRASE_HERE
EOF
chmod 600 /etc/plakar/remote-passphrase
chown root:root /etc/plakar/remote-passphrase

Ajoutez le depot distant :

plakar store add remote \
  https://backup.example.com \
  passphrase_cmd="cat /etc/plakar/remote-passphrase"

Envoyez tous les snapshots de votre depot local vers le depot distant :

plakar at @mybackups sync to @remote

info: sync: synchronization from fs:///var/backups/plakar to https://backup.example.com completed: 3 snapshots synchronized

Plakar lit depuis @mybackups avec sa phrase de passe et ecrit dans @remote avec la phrase de passe de VM2. Seuls les snapshots et blocs de donnees manquants sont transferes. Les synchronisations suivantes ignorent les donnees deja presentes sur le serveur distant.

Envoyez un seul snapshot par ID :

plakar at @mybackups sync a5bcf13b to @remote

Synchronisez uniquement les snapshots recents des 7 derniers jours :

plakar at @mybackups sync -since 7d to @remote

Comment verifier la replication sur le serveur distant ?

Sur VM2, listez les snapshots pour confirmer leur arrivee :

plakar at @backups ls

2026-03-20T10:05:12Z   a5bcf13b   1.4 MiB        0s /etc
2026-03-20T10:06:01Z   5fc17459       0 B        0s /home
2026-03-20T10:06:15Z   7ed22fb8      24 B        0s /var/www

Les ID de snapshots et les horodatages correspondent a ceux de VM1. Restaurez un fichier unique depuis un snapshot synchronise pour verifier l'integrite des donnees :

plakar at @backups cat a5bcf13b:/etc/hostname

Le hostname de VM1 s'affiche sur stdout. Pour un test de restauration complet :

mkdir -p /tmp/restore-test
plakar at @backups restore -to /tmp/restore-test a5bcf13b
ls /tmp/restore-test/etc/

info: a5bcf13b: OK /etc
info: restore: restoration of a5bcf13b:/etc at /tmp/restore-test completed successfully

rm -rf /tmp/restore-test

Comment synchroniser les sauvegardes plakar vers un stockage compatible S3 ?

Ajoutez un bucket compatible S3 comme depot nomme, puis envoyez les snapshots avec plakar sync. Cela fonctionne avec tout fournisseur qui parle le protocole S3. Vous fournissez votre propre endpoint, bucket et identifiants. Aucune configuration specifique au fournisseur n'est requise cote plakar.

Comment installer l'integration S3 ?

Le backend S3 est un plugin, comme HTTP. Compilez-le depuis les sources :

curl -fsSL https://plugins.plakar.io/kloset/recipe/v1.0.0/s3.yaml -o /tmp/s3.yaml
plakar pkg build /tmp/s3.yaml
plakar pkg add ./s3_v1.0.7_linux_amd64.ptar

Si Go et Make ne sont pas encore installes (ils le sont si vous avez deja fait le plugin HTTP), installez-les d'abord : apt install -y golang-go make.

Les deux plugins devraient maintenant etre installes :

plakar pkg list

http@v1.0.5
s3@v1.0.7

Comment ajouter un depot S3 ?

Creez d'abord un bucket chez votre fournisseur S3. Le bucket doit deja exister. Plakar ne cree pas les buckets.

Ajoutez le depot S3 avec plakar store add. Remplacez l'endpoint, le nom du bucket et les identifiants par les votres :

plakar store add s3 \
  s3://s3.eu-west-1.example.com/my-plakar-backups \
  access_key=YOUR_ACCESS_KEY \
  secret_access_key=YOUR_SECRET_KEY \
  use_tls=true \
  passphrase_cmd="cat /etc/plakar/passphrase"

Le format de localisation s3:// est s3://endpoint/nom-du-bucket. Definissez use_tls=true pour les connexions HTTPS vers l'endpoint S3. Le passphrase_cmd retourne la phrase de passe pour chiffrer les donnees dans ce nouveau depot Kloset.

Initialisez un depot Kloset dans le bucket :

plakar at @s3 create

Plakar demande une phrase de passe. Entrez la meme phrase de passe que celle retournee par passphrase_cmd. Cela cree la structure Kloset (metadonnees, index) dans le bucket. Le bucket lui-meme stocke les objets de donnees chiffres.

Comment envoyer les snapshots vers S3 ?

Envoyez tous les snapshots de votre depot local vers S3 :

plakar at @mybackups sync to @s3

info: sync: synchronization from fs:///var/backups/plakar to s3://s3.eu-west-1.example.com/my-plakar-backups completed: 3 snapshots synchronized

Envoyez un seul snapshot :

plakar at @mybackups sync a5bcf13b to @s3

Listez les snapshots sur le depot S3 pour confirmer :

plakar at @s3 ls

2026-03-20T10:05:12Z   a5bcf13b   1.4 MiB        0s /etc
2026-03-20T10:06:01Z   5fc17459       0 B        0s /home
2026-03-20T10:06:15Z   7ed22fb8      24 B        0s /var/www

Restaurez un fichier depuis le depot S3 :

plakar at @s3 cat a5bcf13b:/etc/hostname

Pour une restauration complete d'un repertoire depuis S3 :

mkdir -p /tmp/restore-test
plakar at @s3 restore -to /tmp/restore-test a5bcf13b:/etc/ssh
ls /tmp/restore-test/etc/ssh/
rm -rf /tmp/restore-test

Quelles permissions S3 plakar necessite-t-il ?

Vos identifiants S3 ont besoin de ces permissions minimales sur le bucket :

  • s3:GetObject et s3:ListBucket pour lire les snapshots et les metadonnees
  • s3:PutObject pour ecrire de nouveaux snapshots
  • s3:DeleteObject pour le nettoyage des verrous pendant les operations de synchronisation

Creez un utilisateur IAM dedie ou un compte de service avec une politique limitee au seul bucket de sauvegarde. Ne reutilisez pas des identifiants ayant un acces plus large.

Si votre fournisseur prend en charge le versionnage de bucket et le verrouillage d'objets, activez les deux. Le versionnage protege contre les ecrasements accidentels. Le verrouillage d'objets (en mode conformite ou gouvernance) empeche la suppression des donnees de sauvegarde pendant une periode de retention configurable. C'est votre derniere ligne de defense contre les rancongiciels qui compromettent le serveur source et ses identifiants S3.

Comment automatiser les sauvegardes et la synchronisation plakar ?

Configurez le planificateur plakar pour les sauvegardes locales, puis enchainez la synchronisation hors site avec un timer systemd. L'objectif : les sauvegardes s'executent selon un calendrier, puis les snapshots se synchronisent automatiquement vers la destination distante. Aucune intervention manuelle apres la configuration initiale.

Comment configurer les depots pour le fonctionnement sans surveillance ?

Si vous avez suivi Sauvegarder votre VPS Linux avec Plakar, vous avez deja un depot nomme mybackups avec un passphrase_cmd. Vous avez egalement besoin du depot hors site (remote ou s3) configure avec passphrase_cmd comme indique dans les sections precedentes. Les deux depots doivent fonctionner sans invite interactive pour que l'automatisation fonctionne.

Testez que les deux depots sont accessibles :

plakar at @mybackups ls
plakar at @remote ls

Si l'une des commandes demande une phrase de passe, le passphrase_cmd n'est pas configure correctement. Revenez en arriere et corrigez-le avant de continuer.

Comment ecrire un scheduler.yaml pour plakar ?

Le planificateur plakar execute des taches de sauvegarde a des intervalles definis. Il gere nativement les sauvegardes de systeme de fichiers. Creez une configuration de planificateur :

cat > /etc/plakar/scheduler.yaml <<'EOF'
agent:
  tasks:
    - name: backup etc
      repository: "@mybackups"
      backup:
        path: /etc
        interval: 24h
        check: true
    - name: backup home
      repository: "@mybackups"
      backup:
        path: /home
        interval: 24h
    - name: backup www
      repository: "@mybackups"
      backup:
        path: /var/www
        interval: 24h
EOF
chmod 600 /etc/plakar/scheduler.yaml

Chaque tache specifie un depot, un chemin et un intervalle. L'option check: true sur la premiere tache execute une verification d'integrite apres chaque sauvegarde. Ajoutez-la a toutes les taches si vous privilegiez la securite a la vitesse.

Le planificateur ne supporte pas nativement la synchronisation comme type de tache. Utilisez un script wrapper et un timer systemd pour l'etape de synchronisation.

Comment synchroniser automatiquement apres les sauvegardes ?

Creez un script wrapper qui synchronise tous les snapshots vers votre destination hors site :

cat > /etc/plakar/sync-offsite.sh <<'SCRIPT'
#!/bin/bash
set -euo pipefail

# Change to "s3" if using S3 instead of a remote server
OFFSITE_STORE="remote"

echo "$(date -Iseconds) Starting offsite sync to @${OFFSITE_STORE}"
plakar at @mybackups sync to @${OFFSITE_STORE}
echo "$(date -Iseconds) Offsite sync complete"
SCRIPT
chmod 700 /etc/plakar/sync-offsite.sh

Testez le script manuellement :

/etc/plakar/sync-offsite.sh

2026-03-20T14:00:00+00:00 Starting offsite sync to @remote
info: sync: synchronization from fs:///var/backups/plakar to https://backup.example.com completed: 0 snapshots synchronized
2026-03-20T14:00:01+00:00 Offsite sync complete

Si vous utilisez a la fois un serveur distant et S3, ajoutez une seconde ligne de synchronisation au script :

plakar at @mybackups sync to @remote
plakar at @mybackups sync to @s3

Comment executer le planificateur plakar comme service systemd ?

Creez une unite systemd pour le planificateur sur VM1. Le drapeau -foreground maintient le planificateur au premier plan pour que systemd puisse suivre le processus :

cat > /etc/systemd/system/plakar-scheduler.service <<EOF
[Unit]
Description=Plakar Backup Scheduler
After=network.target

[Service]
Type=simple
ExecStart=/usr/bin/plakar scheduler start -foreground -tasks /etc/plakar/scheduler.yaml
ExecStop=/usr/bin/plakar scheduler stop
Restart=on-failure
RestartSec=30
User=root
StandardOutput=journal
StandardError=journal

[Install]
WantedBy=multi-user.target
EOF

Creez un timer systemd pour le script de synchronisation hors site. Planifiez-le pour s'executer quotidiennement apres que les sauvegardes aient eu le temps de se terminer. Si vos taches de planificateur utilisent un intervalle de 24h a partir de minuit, reglez la synchronisation quelques heures plus tard :

cat > /etc/systemd/system/plakar-sync.service <<EOF
[Unit]
Description=Plakar Offsite Sync
After=network.target

[Service]
Type=oneshot
ExecStart=/etc/plakar/sync-offsite.sh
User=root
StandardOutput=journal
StandardError=journal
EOF

cat > /etc/systemd/system/plakar-sync.timer <<EOF
[Unit]
Description=Run Plakar Offsite Sync Daily

[Timer]
OnCalendar=*-*-* 03:30:00
Persistent=true

[Install]
WantedBy=timers.target
EOF

Persistent=true signifie que si le serveur etait eteint quand le timer aurait du se declencher, systemd execute la synchronisation immediatement au prochain demarrage.

Activez le tout :

systemctl daemon-reload
systemctl enable --now plakar-scheduler.service
systemctl enable --now plakar-sync.timer

info: Plakar scheduler up

Le planificateur tourne :

systemctl status plakar-scheduler.service

● plakar-scheduler.service - Plakar Backup Scheduler
     Loaded: loaded (/etc/systemd/system/plakar-scheduler.service; enabled; preset: enabled)
     Active: active (running)

Le timer de synchronisation est programme :

systemctl list-timers plakar-sync.timer

NEXT                         LEFT          LAST  PASSED  UNIT                  ACTIVATES
Fri 2026-03-21 03:30:00 UTC  15h left      n/a   n/a     plakar-sync.timer     plakar-sync.service

Surveillez les journaux du planificateur et de la synchronisation :

journalctl -u plakar-scheduler.service --since today
journalctl -u plakar-sync.service --since today

Si vous executez egalement le script de sauvegarde de base de donnees de Sauvegarder votre VPS Linux avec Plakar, chainez le timer de synchronisation pour s'executer apres la fin des sauvegardes de base de donnees. Ajoutez After=plakar-db-backup.service a la section [Unit] de plakar-sync.service, et ajustez OnCalendar dans le timer pour s'executer apres le declenchement du timer de base de donnees.

Quelque chose ne fonctionne pas ?

"backend 'http' does not exist" ou "backend 's3' does not exist". Le plugin d'integration n'est pas installe. Compilez-le depuis les sources avec plakar pkg build et la recette du serveur de plugins comme indique dans les sections d'installation HTTP ou S3 ci-dessus. Lancez plakar pkg list pour voir ce qui est installe.

"connection refused" lors de la synchronisation vers le distant. Verifiez que plakar server tourne sur VM2 : systemctl status plakar-server.service. Verifiez que Caddy tourne : systemctl status caddy. Confirmez que votre enregistrement DNS A pointe vers l'IP de VM2. Testez depuis VM1 :

curl -I https://backup.example.com

Une erreur "connection refused" a ce stade signifie que Caddy est arrete, le DNS est incorrect ou le port 443 est bloque par un pare-feu.

"TLS handshake error" de Caddy. Caddy n'a pas pu obtenir un certificat de Let's Encrypt. Causes frequentes : DNS pas encore propage (attendez quelques minutes et reessayez), port 80 bloque (Caddy en a besoin pour le challenge ACME HTTP-01), ou limites de debit atteintes. Consultez les journaux de Caddy :

journalctl -u caddy --since "10 minutes ago"

Invite "passphrase" pendant la synchronisation. Le passphrase_cmd de l'un des depots n'est pas configure ou retourne une chaine vide. Verifiez les deux fichiers de phrase de passe :

cat /etc/plakar/passphrase
cat /etc/plakar/remote-passphrase

Les deux fichiers doivent contenir la bonne phrase de passe pour leurs depots respectifs. Verifiez que les permissions sont 600 et que le proprietaire est root.

"access denied" lors de la synchronisation S3. Reverifiez votre cle d'acces et votre cle secrete. Confirmez que la politique IAM accorde s3:GetObject, s3:PutObject, s3:ListBucket et s3:DeleteObject sur le bucket. Certains fournisseurs exigent la region du bucket dans l'URL de l'endpoint. Reverifiez le format de l'URL s3://.

Le planificateur s'arrete immediatement. Sans le drapeau -foreground, plakar scheduler start se demonise et l'unite systemd le considere comme termine. Assurez-vous que votre ligne ExecStart inclut -foreground :

ExecStart=/usr/bin/plakar scheduler start -foreground -tasks /etc/plakar/scheduler.yaml

Rechargez et redemarrez : systemctl daemon-reload && systemctl restart plakar-scheduler.service.

La synchronisation prend longtemps lors du premier lancement. La synchronisation initiale transfere tous les snapshots existants et leurs blocs de donnees. Les synchronisations suivantes sont incrementales et n'envoient que les nouvelles donnees. Si vous avez de nombreux snapshots volumineux, la premiere synchronisation peut prendre des heures selon la bande passante montante. Lancez-la dans une session tmux ou screen pour eviter les interruptions.

Snapshots manquants cote distant. Comparez les listes de snapshots :

plakar at @mybackups ls
plakar at @remote ls

Si les nombres different, relancez la synchronisation. La synchronisation est idempotente. Les snapshots existants sont ignores. Si une synchronisation a ete interrompue, la relancer reprend la ou elle s'etait arretee.

Le planificateur ne tourne pas apres un redemarrage. Verifiez que le service est active :

systemctl is-enabled plakar-scheduler.service

La sortie devrait indiquer enabled. Si elle indique disabled, lancez systemctl enable plakar-scheduler.service.

Le timer de synchronisation ne se declenche pas. Verifiez si le timer est actif :

systemctl is-active plakar-sync.timer

S'il indique inactive, activez-le : systemctl enable --now plakar-sync.timer. Consultez systemctl list-timers pour voir quand le prochain lancement est programme.

Pour les charges Docker, envisagez Sauvegarder et restaurer les volumes Docker sur un VPS en complement de cette configuration pour sauvegarder les volumes Docker avant que plakar ne les snapshotte.

Copyright 2026 Virtua.Cloud. Tous droits reserves. Ce contenu est une creation originale de l'equipe Virtua.Cloud. Toute reproduction, republication ou redistribution sans autorisation ecrite est interdite.

Prêt à essayer ?

Déployez votre serveur en quelques secondes. Linux, Windows ou FreeBSD.

Voir les offres VPS

Articles associés