Offsite-Backup und Replikation mit Plakar

12 Min. Lesezeit·Matthieu·caddydebiansystemds3ubuntuplakaroffsite-backupbackupreplication|

Replizieren Sie plakar-Snapshots auf einen entfernten Server per HTTPS oder in S3-kompatiblen Objektspeicher. Automatisieren Sie Backups und Offsite-Synchronisation mit dem integrierten Scheduler von plakar als systemd-Dienst unter Debian 12 oder Ubuntu 24.04.

Warum brauchen Sie Offsite-Backups?

Lokale Backups schuetzen vor versehentlichem Loeschen und Dateibeschaedigung. Sie schuetzen nicht vor Festplattenausfall, Ransomware oder einem kompromittierten Server. Wenn Ihre Backups auf derselben Maschine wie die Daten liegen, zerstoert ein einzelnes Ereignis beides. Die 3-2-1-Backup-Regel besagt: drei Kopien, zwei verschiedene Medien, eine Kopie offsite. Diese Anleitung behandelt den Offsite-Teil.

Dieser Artikel knuepft an Ihren Linux-VPS mit Plakar sichern an. Sie sollten plakar bereits auf einem Debian 12 oder Ubuntu 24.04 VPS installiert haben, einen lokalen Kloset-Store unter /var/backups/plakar und mindestens einen Snapshot. Falls nicht, beginnen Sie zuerst mit dieser Anleitung.

Zwei Offsite-Optionen sind in plakar integriert. Pfad A repliziert Snapshots auf einen zweiten Server, der plakar server ueber HTTPS ausfuehrt. Pfad B sendet Snapshots an S3-kompatiblen Objektspeicher. Beide verwenden plakar sync und behalten die Kloset-Verschluesselung durchgehend bei. Waehlen Sie einen Pfad oder beide. Der Automatisierungsabschnitt am Ende gilt fuer beide.

Wie replizieren Sie plakar-Snapshots auf einen entfernten Server?

Starten Sie plakar server auf einem zweiten VPS, um einen Kloset-Store ueber HTTP bereitzustellen. Setzen Sie Caddy davor fuer automatisches TLS. Vom Quellrechner aus kompilieren Sie das HTTP-Integrations-Plugin, fuegen den entfernten Server als benannten Store hinzu und senden Snapshots mit plakar sync to. Die Daten bleiben im Kloset-Store verschluesselt gespeichert und per HTTPS verschluesselt uebertragen. Dieser Ansatz gibt Ihnen volle Kontrolle ueber beide Endpunkte.

Sie benoetigen zwei Maschinen fuer diesen Abschnitt. VM1 ist der Produktionsserver mit Ihren bestehenden plakar-Backups. VM2 ist der entfernte Backup-Server in einem anderen Rechenzentrum oder bei einem anderen Anbieter. VM2 benoetigt einen Domainnamen, der auf seine IP-Adresse zeigt, fuer TLS-Zertifikate. Die Beispiele verwenden backup.example.com als Domain.

Alle Befehle in dieser Anleitung werden als root ausgefuehrt. Wenn Sie einen sudo-Benutzer verwenden, stellen Sie jedem Befehl sudo voran.

Wie richten Sie plakar server auf VM2 ein?

Installieren Sie plakar auf VM2 mit denselben Schritten aus dem Hauptartikel:

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

Erstellen Sie einen Kloset-Store auf VM2. Generieren Sie eine starke Passphrase und speichern Sie sie in einem Passwortmanager. Dies ist ein anderer Store als auf VM1, daher bekommt er seine eigene Passphrase:

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

Speichern Sie die Ausgabe. Sie benoetigen diese Passphrase auf VM2 und VM1. Erstellen Sie den Store:

plakar at /var/backups/plakar create

repository passphrase:

Geben Sie die generierte Passphrase ein. Setzen Sie eingeschraenkte Berechtigungen fuer das Store-Verzeichnis:

chmod 700 /var/backups/plakar

Speichern Sie die Passphrase in einer Datei, damit plakar server ohne interaktive Abfrage starten kann:

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

Registrieren Sie den Store mit einem Namen:

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

Starten Sie plakar server, um den Store ueber HTTP bereitzustellen. Binden Sie ihn nur an localhost. Caddy uebernimmt die externen Verbindungen:

plakar at @backups server -listen 127.0.0.1:9876

Der Server laeuft im Vordergrund und protokolliert Anfragen auf stdout. Lassen Sie dieses Terminal geoeffnet. Sie richten spaeter einen systemd-Dienst dafuer ein.

Standardmaessig deaktiviert plakar server Loeschoperationen. Das verhindert, dass entfernte Clients Snapshots entfernen. Fuer die Synchronisation reicht Schreibzugriff. Lassen Sie Loeschungen deaktiviert, es sei denn, Sie haben einen bestimmten Grund, sie zu erlauben.

Wie setzen Sie Caddy vor plakar server fuer TLS ein?

Caddy bietet automatisches HTTPS mit Let's-Encrypt-Zertifikaten. Es terminiert TLS und leitet Anfragen an plakar server auf localhost weiter. Externe Clients verbinden sich ueber Port 443, und Caddy leitet an Port 9876 weiter.

Stellen Sie vor der Installation von Caddy sicher, dass Ihr DNS-A-Eintrag fuer backup.example.com auf die IP-Adresse von VM2 zeigt. Caddy benoetigt dies, um ein TLS-Zertifikat ueber die ACME-HTTP-01-Challenge zu erhalten. Port 80 muss ebenfalls geoeffnet sein.

Installieren Sie Caddy auf 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

Ersetzen Sie die Standard-Caddyfile durch eine Reverse-Proxy-Konfiguration. Ersetzen Sie backup.example.com durch Ihre tatsaechliche Domain:

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

Laden Sie Caddy neu, um die Konfiguration anzuwenden:

systemctl reload caddy
systemctl status caddy

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

Caddy bezieht das TLS-Zertifikat automatisch bei der ersten Anfrage. Testen Sie von VM1 oder einem beliebigen externen Rechner:

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

Eine 200- oder 404-Antwort bedeutet, dass Caddy erfolgreich an den plakar-Server weiterleitet. Ein TLS-Fehler bedeutet, dass das Zertifikat noch nicht bereit ist.

Wie sichern Sie den plakar-Server mit Firewall-Regeln?

Oeffnen Sie die Ports 80 (ACME-Challenge) und 443 (HTTPS). Port 9876 bleibt an 127.0.0.1 gebunden und ist daher auch ohne explizite Blockregel nicht von aussen erreichbar. Fuer eine detaillierte Firewall-Einrichtung siehe Linux-VPS-Firewall mit UFW und nftables einrichten.

Mit UFW:

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

Mit nftables, fuegen Sie Ihrem Regelwerk hinzu:

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

Nach der Ausstellung des Zertifikats koennen Sie Port 80 schliessen, wenn Sie Caddy fuer die TLS-ALPN-01-Challenge konfigurieren. Die Standard-HTTP-01-Challenge erfordert, dass Port 80 fuer Verlaengerungen geoeffnet bleibt.

Wie fuehren Sie plakar server als systemd-Dienst auf VM2 aus?

Erstellen Sie eine systemd-Unit, damit plakar server beim Booten startet und bei Fehlern neu startet:

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

Stoppen Sie den Vordergrund-Server, falls er noch laeuft (Ctrl+C in diesem Terminal), und aktivieren Sie dann den systemd-Dienst. enable --now sorgt dafuer, dass er Neustarts ueberlebt und sofort gestartet wird:

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)

Ueberwachen Sie die Server-Logs:

journalctl -u plakar-server.service -f

Wie installieren Sie die HTTP-Integration auf VM1?

Zurueck auf VM1. Plakar benoetigt die HTTP-Integration, um sich mit entfernten Stores zu verbinden. Das HTTP-Backend ist ein Plugin, das separat vom Hauptpaket geliefert wird. Kompilieren Sie es aus dem Quellcode mit dem Rezept vom plakar-Plugin-Server. Dafuer werden Go und Make benoetigt:

apt install -y golang-go make

Laden Sie die Rezeptdatei herunter und kompilieren Sie das Plugin:

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

Die Kompilierung erstellt die HTTP-Integration aus ihrem Quell-Repository und erzeugt ein .ptar-Archiv im aktuellen Verzeichnis. Installieren Sie das kompilierte Plugin:

plakar pkg add ./http_v1.0.5_linux_amd64.ptar

Der genaue Dateiname haengt von Version und Architektur ab. Pruefen Sie, was pkg build erzeugt hat, mit ls *.ptar. Listen Sie die installierten Plugins auf:

plakar pkg list

http@v1.0.5

Wie synchronisieren Sie Snapshots von VM1 zum entfernten Server?

Registrieren Sie den entfernten Server als benannten Store. Ersetzen Sie backup.example.com durch Ihre Domain. Der passphrase_cmd muss die Passphrase des VM2-Stores zurueckgeben, nicht die von VM1. Kopieren Sie die Passphrase von VM2 in eine separate Datei auf 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

Fuegen Sie den entfernten Store hinzu:

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

Senden Sie alle Snapshots aus Ihrem lokalen Store an den entfernten:

plakar at @mybackups sync to @remote

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

Plakar liest aus @mybackups mit dessen Passphrase und schreibt in @remote mit der Passphrase von VM2. Nur fehlende Snapshots und Datenbloecke werden uebertragen. Nachfolgende Synchronisationen ueberspringen Daten, die bereits auf dem entfernten Server vorhanden sind.

Senden Sie einen einzelnen Snapshot anhand der ID:

plakar at @mybackups sync a5bcf13b to @remote

Synchronisieren Sie nur Snapshots der letzten 7 Tage:

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

Wie ueberpruefen Sie die Replikation auf dem entfernten Server?

Auf VM2, listen Sie die Snapshots auf, um deren Ankunft zu bestaetigen:

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

Die Snapshot-IDs und Zeitstempel stimmen mit denen auf VM1 ueberein. Stellen Sie eine einzelne Datei aus einem synchronisierten Snapshot wieder her, um die Datenintegritaet zu pruefen:

plakar at @backups cat a5bcf13b:/etc/hostname

Der Hostname von VM1 wird auf stdout ausgegeben. Fuer einen vollstaendigen Wiederherstellungstest:

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

Wie synchronisieren Sie plakar-Backups in S3-kompatiblen Speicher?

Fuegen Sie einen S3-kompatiblen Bucket als benannten Store hinzu und senden Sie Snapshots mit plakar sync. Dies funktioniert mit jedem Anbieter, der das S3-Protokoll unterstuetzt. Sie bringen Ihren eigenen Endpunkt, Bucket und Zugangsdaten mit. Keine anbieterspezifische Konfiguration ist auf der plakar-Seite erforderlich.

Wie installieren Sie die S3-Integration?

Das S3-Backend ist ein Plugin, wie HTTP. Kompilieren Sie es aus dem Quellcode:

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

Falls Go und Make noch nicht installiert sind (sie sind es, wenn Sie bereits das HTTP-Plugin erstellt haben), installieren Sie sie zuerst: apt install -y golang-go make.

Beide Plugins sollten jetzt installiert sein:

plakar pkg list

http@v1.0.5
s3@v1.0.7

Wie fuegen Sie einen S3-Store hinzu?

Erstellen Sie zuerst einen Bucket bei Ihrem S3-Anbieter. Der Bucket muss bereits existieren. Plakar erstellt keine Buckets.

Fuegen Sie den S3-Store mit plakar store add hinzu. Ersetzen Sie den Endpunkt, den Bucketnamen und die Zugangsdaten durch Ihre eigenen:

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"

Das s3://-Standortformat ist s3://endpoint/bucket-name. Setzen Sie use_tls=true fuer HTTPS-Verbindungen zum S3-Endpunkt. Der passphrase_cmd gibt die Passphrase zur Verschluesselung der Daten in diesem neuen Kloset-Store zurueck.

Initialisieren Sie einen Kloset-Store im Bucket:

plakar at @s3 create

Plakar fragt nach einer Passphrase. Geben Sie dieselbe Passphrase ein, die passphrase_cmd zurueckgibt. Dies erstellt die Kloset-Struktur (Metadaten, Indizes) im Bucket. Der Bucket selbst speichert die verschluesselten Datenobjekte.

Wie senden Sie Snapshots an S3?

Senden Sie alle Snapshots aus Ihrem lokalen Store an 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

Senden Sie einen einzelnen Snapshot:

plakar at @mybackups sync a5bcf13b to @s3

Listen Sie die Snapshots im S3-Store auf:

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

Stellen Sie eine Datei aus dem S3-Store wieder her:

plakar at @s3 cat a5bcf13b:/etc/hostname

Fuer eine vollstaendige Verzeichnis-Wiederherstellung aus 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

Welche S3-Berechtigungen benoetigt plakar?

Ihre S3-Zugangsdaten benoetigen diese Mindestberechtigungen fuer den Bucket:

  • s3:GetObject und s3:ListBucket zum Lesen von Snapshots und Metadaten
  • s3:PutObject zum Schreiben neuer Snapshots
  • s3:DeleteObject fuer die Bereinigung von Sperren waehrend der Synchronisation

Erstellen Sie einen dedizierten IAM-Benutzer oder ein Dienstkonto mit einer Richtlinie, die nur auf den Backup-Bucket beschraenkt ist. Verwenden Sie keine Zugangsdaten mit breiterem Zugriff.

Wenn Ihr Anbieter Bucket-Versionierung und Object Lock unterstuetzt, aktivieren Sie beides. Versionierung schuetzt vor versehentlichem Ueberschreiben. Object Lock (im Compliance- oder Governance-Modus) verhindert das Loeschen von Backup-Daten fuer einen konfigurierbaren Aufbewahrungszeitraum. Dies ist Ihre letzte Verteidigungslinie gegen Ransomware, die den Quellserver und seine S3-Zugangsdaten kompromittiert.

Wie automatisieren Sie plakar-Backups und Synchronisation?

Richten Sie den plakar-Scheduler fuer lokale Backups ein und verketten Sie dann die Offsite-Synchronisation mit einem systemd-Timer. Das Ziel: Backups laufen nach Zeitplan, dann synchronisieren sich Snapshots automatisch zum entfernten Ziel. Keine manuelle Intervention nach der Ersteinrichtung.

Wie konfigurieren Sie Stores fuer den unbeaufsichtigten Betrieb?

Wenn Sie Ihren Linux-VPS mit Plakar sichern gefolgt sind, haben Sie bereits einen benannten Store mybackups mit einem passphrase_cmd. Sie benoetigen ausserdem den Offsite-Store (remote oder s3), konfiguriert mit passphrase_cmd wie in den vorherigen Abschnitten gezeigt. Beide Stores muessen ohne interaktive Abfragen funktionieren.

Testen Sie, ob beide Stores erreichbar sind:

plakar at @mybackups ls
plakar at @remote ls

Wenn einer der Befehle nach einer Passphrase fragt, ist der passphrase_cmd nicht korrekt konfiguriert. Gehen Sie zurueck und beheben Sie das, bevor Sie fortfahren.

Wie schreiben Sie eine scheduler.yaml fuer plakar?

Der plakar-Scheduler fuehrt Backup-Aufgaben in definierten Intervallen aus. Er verarbeitet Dateisystem-Backups nativ. Erstellen Sie eine Scheduler-Konfiguration:

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

Jede Aufgabe spezifiziert ein Repository, einen Pfad und ein Intervall. Die Option check: true bei der ersten Aufgabe fuehrt eine Integritaetspruefung nach jedem Backup durch. Fuegen Sie sie allen Aufgaben hinzu, wenn Sie Sicherheit der Geschwindigkeit vorziehen.

Der Scheduler unterstuetzt Synchronisation nicht nativ als Aufgabentyp. Verwenden Sie ein Wrapper-Skript und einen systemd-Timer fuer den Synchronisationsschritt.

Wie synchronisieren Sie automatisch nach den Backups?

Erstellen Sie ein Wrapper-Skript, das alle Snapshots zu Ihrem Offsite-Ziel synchronisiert:

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

Testen Sie das Skript manuell:

/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

Wenn Sie sowohl einen entfernten Server als auch S3 verwenden, fuegen Sie dem Skript eine zweite Synchronisationszeile hinzu:

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

Wie fuehren Sie den plakar-Scheduler als systemd-Dienst aus?

Erstellen Sie eine systemd-Unit fuer den Scheduler auf VM1. Das Flag -foreground haelt den Scheduler im Vordergrund, damit systemd den Prozess verfolgen kann:

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

Erstellen Sie einen systemd-Timer fuer das Offsite-Synchronisationsskript. Planen Sie ihn taeglich, nachdem die Backups Zeit hatten, fertig zu werden:

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 bedeutet: Wenn der Server ausgeschaltet war, als der Timer haette ausloesen sollen, fuehrt systemd die Synchronisation sofort beim naechsten Start aus.

Aktivieren Sie alles:

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

info: Plakar scheduler up

Der Scheduler laeuft:

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)

Der Synchronisations-Timer ist geplant:

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

Ueberwachen Sie die Scheduler- und Synchronisationslogs:

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

Wenn Sie auch das Datenbank-Backup-Skript aus Ihren Linux-VPS mit Plakar sichern ausfuehren, verketten Sie den Synchronisations-Timer, um nach Abschluss der Datenbank-Backups zu laufen. Fuegen Sie After=plakar-db-backup.service zum Abschnitt [Unit] von plakar-sync.service hinzu und passen Sie OnCalendar im Timer an.

Etwas funktioniert nicht?

"backend 'http' does not exist" oder "backend 's3' does not exist". Das Integrations-Plugin ist nicht installiert. Kompilieren Sie es aus dem Quellcode mit plakar pkg build und dem Rezept vom Plugin-Server wie in den HTTP- oder S3-Installationsabschnitten oben gezeigt. Fuehren Sie plakar pkg list aus, um zu sehen, was installiert ist.

"connection refused" bei der Synchronisation zum entfernten Server. Pruefen Sie, ob plakar server auf VM2 laeuft: systemctl status plakar-server.service. Pruefen Sie, ob Caddy laeuft: systemctl status caddy. Bestaetigen Sie, dass Ihr DNS-A-Eintrag auf die IP von VM2 zeigt. Testen Sie von VM1:

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

Ein "connection refused"-Fehler bedeutet, dass entweder Caddy nicht laeuft, DNS falsch ist oder Port 443 durch eine Firewall blockiert wird.

"TLS handshake error" von Caddy. Caddy konnte kein Zertifikat von Let's Encrypt erhalten. Haeufige Ursachen: DNS noch nicht propagiert (warten Sie einige Minuten und versuchen Sie es erneut), Port 80 blockiert (Caddy benoetigt ihn fuer die ACME-HTTP-01-Challenge), oder Rate-Limits erreicht. Pruefen Sie die Caddy-Logs:

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

Passphrase-Abfrage waehrend der Synchronisation. Der passphrase_cmd eines der Stores ist nicht konfiguriert oder gibt einen leeren String zurueck. Pruefen Sie beide Passphrase-Dateien:

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

Beide Dateien muessen die richtige Passphrase fuer ihre jeweiligen Stores enthalten. Pruefen Sie, ob die Berechtigungen 600 sind und der Eigentuemer root ist.

"access denied" bei der S3-Synchronisation. Ueberpruefen Sie Ihren Zugriffsschluessel und geheimen Schluessel. Bestaetigen Sie, dass die IAM-Richtlinie s3:GetObject, s3:PutObject, s3:ListBucket und s3:DeleteObject fuer den Bucket gewaehrt. Manche Anbieter erfordern die Bucket-Region in der Endpunkt-URL. Ueberpruefen Sie das s3://-URL-Format.

Scheduler beendet sich sofort. Ohne das Flag -foreground daemonisiert sich plakar scheduler start und die systemd-Unit betrachtet ihn als beendet. Stellen Sie sicher, dass Ihre ExecStart-Zeile -foreground enthaelt:

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

Neu laden und neu starten: systemctl daemon-reload && systemctl restart plakar-scheduler.service.

Die Synchronisation dauert beim ersten Mal lange. Die initiale Synchronisation uebertraegt alle bestehenden Snapshots und deren Datenbloecke. Nachfolgende Synchronisationen sind inkrementell und senden nur neue Daten. Bei vielen grossen Snapshots kann die erste Synchronisation je nach Upload-Bandbreite Stunden dauern. Fuehren Sie sie in einer tmux- oder screen-Sitzung aus.

Snapshots fehlen auf der entfernten Seite. Vergleichen Sie die Snapshot-Listen:

plakar at @mybackups ls
plakar at @remote ls

Wenn die Anzahl abweicht, fuehren Sie die Synchronisation erneut aus. Die Synchronisation ist idempotent. Bestehende Snapshots werden uebersprungen.

Scheduler laeuft nicht nach dem Neustart. Pruefen Sie, ob der Dienst aktiviert ist:

systemctl is-enabled plakar-scheduler.service

Die Ausgabe sollte enabled lauten. Falls disabled, fuehren Sie systemctl enable plakar-scheduler.service aus.

Synchronisations-Timer loest nicht aus. Pruefen Sie, ob der Timer aktiv ist:

systemctl is-active plakar-sync.timer

Falls inactive, aktivieren Sie ihn: systemctl enable --now plakar-sync.timer. Pruefen Sie systemctl list-timers, um den naechsten geplanten Lauf zu sehen.

Fuer Docker-Workloads sollten Sie Docker-Volumes auf einem VPS sichern und wiederherstellen zusammen mit diesem Setup in Betracht ziehen, um Docker-Volumes zu sichern, bevor plakar sie snapshottet.

Bereit, es selbst auszuprobieren?

Stellen Sie Ihren eigenen Server in Sekunden bereit. Linux, Windows oder FreeBSD. →

Verwandte Artikel