Bist du selber in der Lage den Code einer KI zu bewerten, ob er gut ist oder nicht? Funktionieren ist kein Kriterium dafür. Es bringt nichts, wenn es funktioniert, aber da Sicherheitslücken ohne Ende drin sind. Oder nur der Happy Path ordentlich läuft. Das ist halt nicht alles so schön wie man denkt bei der tollen KI.
snap shots Backup script
- Thread starter hackmann
- Start date
das script
Code:
#!/bin/bash
# ==============================================================================
# SCRIPT: 01_backup_remote.sh (V3 - Robust-Edition)
# ZWECK: ZFS Snapshots + System-Konfig + Sicherheits-Checks + Push
# ==============================================================================
# --- 1. INITIALISIERUNG & KONFIGURATION ---
source /usr/local/sbin/01_backup/001_global_config.sh
BLUE='\033[0;34m'
YELLOW='\033[1;33m'
GREEN='\033[0;32m'
RED='\033[0;31m'
NC='\033[0m'
ALERT=0
START_TIME=$(date +%s)
TIMESTAMP=$(date '+%Y-%m-%d_%H-%M-%S')
SYS_REMOTE_PATH="${BACKUPPOOL}/sysdata-${MY_IP##*.}"
clear
echo -e "${BLUE}================================================================${NC}"
echo -e " Start ZFS & System Remote-Backup: $(date '+%d.%m.%Y %H:%M')"
echo -e "️ Quelle: ${YELLOW}$HOST ($MY_IP)${NC} | Ziel: ${YELLOW}$REMOTE_HOST${NC}"
echo -e "${BLUE}================================================================${NC}\n"
# --- 2. PRE-FLIGHT CHECKS (Sicherheits-Prüfungen) ---
echo -e "${BLUE}▶ Starte Sicherheits-Checks...${NC}"
# A) Ist der Quell-Pool gesund?
POOL_HEALTH=$(zpool status "$MASTERPOOL" | grep "state:" | awk '{print $2}')
if [ "$POOL_HEALTH" != "ONLINE" ]; then
msg=" ABBRUCH: Quell-Pool $MASTERPOOL ist $POOL_HEALTH! Backup riskant."
echo -e "${RED}$msg${NC}"
[ -f "$SEND_PUSH" ] && "$SEND_PUSH" "$msg" warn
exit 1
fi
# B) Ist der Ziel-Server per Ping erreichbar?
if ! ping -c 1 -W 2 "$REMOTE_HOST" >/dev/null 2>&1; then
msg=" ABBRUCH: Ziel-Server $REMOTE_HOST ist nicht erreichbar (Ping failed)!"
echo -e "${RED}$msg${NC}"
[ -f "$SEND_PUSH" ] && "$SEND_PUSH" "$msg" warn
exit 1
fi
# C) Speicherplatz auf dem Ziel-Pool prüfen (Abbruch bei > 95%)
REMOTE_USAGE=$(ssh root@$REMOTE_HOST "zfs list -H -o capacity $BACKUPPOOL" 2>/dev/null | cut -d'%' -f1)
if [ -n "$REMOTE_USAGE" ] && [ "$REMOTE_USAGE" -gt 95 ]; then
msg=" ABBRUCH: Ziel-Pool $BACKUPPOOL ist zu $REMOTE_USAGE% voll!"
echo -e "${RED}$msg${NC}"
[ -f "$SEND_PUSH" ] && "$SEND_PUSH" "$msg" warn
exit 1
fi
echo -e " ✅ Sicherheits-Checks bestanden (Pool OK, Ping OK, Platz: ${REMOTE_USAGE:-0}%).\n"
# --- 3. SYSTEM-KONFIGURATION SICHERN (/etc & Paketliste) ---
echo -e "${BLUE}▶ Sichere System-Konfiguration...${NC}"
ssh root@$REMOTE_HOST "mkdir -p /${SYS_REMOTE_PATH}/etc" 2>/dev/null
dpkg --get-selections > /tmp/packages.txt
rsync -az /tmp/packages.txt root@$REMOTE_HOST:/${SYS_REMOTE_PATH}/ 2>/dev/null
rm -f /tmp/packages.txt
if rsync -avz --delete /etc/ root@$REMOTE_HOST:/${SYS_REMOTE_PATH}/etc/ >/dev/null 2>&1; then
echo -e " ✅ /etc & Paketliste nach ${YELLOW}${SYS_REMOTE_PATH}${NC} gesichert.\n"
else
msg=" SYSTEM-BACKUP FEHLER: /etc auf $HOST konnte nicht übertragen werden."
echo -e " ❌ ${RED}$msg${NC}\n"
[ -f "$SEND_PUSH" ] && "$SEND_PUSH" "$msg" warn
ALERT=1
fi
# --- 4. ZFS BACKUP-SCHLEIFE ---
for DS in "${DATASETS[@]}"; do
MASTER_DS="${MASTERPOOL}/${DS}"
TARGET_DS="${BACKUPPOOL}/pve_${MY_IP}/${DS}"
NEWSNAP="${MASTER_DS}@${PREFIX}-${TIMESTAMP}"
echo -e "${BLUE}▶ ZFS Dataset:${NC} ${YELLOW}$DS${NC}"
# Snapshot erstellen
if zfs snapshot "$NEWSNAP" 2>/dev/null; then
echo -e " ✅ Snapshot: ${PREFIX}-${TIMESTAMP}"
else
msg=" SNAPSHOT FEHLER: $DS auf $HOST fehlgeschlagen!"
echo -e " ❌ ${RED}$msg${NC}"
[ -f "$SEND_PUSH" ] && "$SEND_PUSH" "$msg" warn
ALERT=1; continue
fi
# Remote-Check & Transfer
LAST_REMOTE_SNAP=$(ssh root@$REMOTE_HOST "zfs list -H -t snapshot -o name -s creation $TARGET_DS" 2>/dev/null | grep "@${PREFIX}-" | tail -1 | cut -d@ -f2)
if [ -z "$LAST_REMOTE_SNAP" ]; then
echo -e " ${YELLOW}Modus: FULL-TRANSFER${NC}"
zfs send -cL "$NEWSNAP" | pv -N "Full: $DS" | mbuffer -m 256M | ssh root@$REMOTE_HOST "zfs recv -Fp $TARGET_DS"
else
echo -e " ${YELLOW}Modus: INKREMENTELL (ab $LAST_REMOTE_SNAP)$NC"
zfs send -cL -i "${MASTER_DS}@${LAST_REMOTE_SNAP}" "$NEWSNAP" | pv -N "Incr: $DS" | mbuffer -m 256M | ssh root@$REMOTE_HOST "zfs recv -Fu $TARGET_DS"
fi
if [ ${PIPESTATUS[0]} -eq 0 ]; then
echo -e " ✨ ${GREEN}ZFS Transfer erfolgreich.${NC}\n"
else
msg=" ZFS TRANSFER FEHLER: $DS konnte nicht an $REMOTE_HOST gesendet werden!"
echo -e " ${RED}$msg${NC}\n"
[ -f "$SEND_PUSH" ] && "$SEND_PUSH" "$msg" warn
ALERT=1
fi
# Retention (Aufräumen)
zfs list -H -t snapshot -o name -s creation "$MASTER_DS" | grep "@${PREFIX}-" | head -n -"$KEEPOLD_MASTER" | xargs -n 1 zfs destroy -r 2>/dev/null
ssh root@$REMOTE_HOST "zfs list -H -t snapshot -o name -s creation $TARGET_DS | grep '@${PREFIX}-' | head -n -"$KEEPOLD_BACKUP" | xargs -n 1 zfs destroy -r 2>/dev/null"
done
# --- 5. ABSCHLUSS & PUSH ---
DURATION=$(( $(date +%s) - START_TIME ))
if [ $ALERT -eq 0 ]; then
PUSH_TEXT="✅ Backup OK: $HOST -> $REMOTE_HOST (${DURATION}s). /etc & Datasets synchron."
[ -f "$SEND_PUSH" ] && "$SEND_PUSH" "$PUSH_TEXT" success
echo -e "${GREEN} Alles erledigt. Erfolgs-Push gesendet.${NC}"
else
echo -e "${RED} Backup mit Fehlern beendet. Warnungen wurden gesendet.${NC}"
fi
echo -e "${BLUE}================================================================${NC}"Wie erwartet, stumpfer KI Slop.
KI ist halt echt eine Dunning Kruger Machine.
Ist nett gemeint Kleiner, aber glaube niemand hat hier interesse an einem Backup KI Slop von jemandem, der noch nicht mal weiss, wie er 4 Dateien auf Github teilt.
Nur mal so als kleiner Input, warum dein Script strunzdumm ist:
- Ob der Quell Pool gesund ist, geht ein Backup tool nix an. Was wenn dieser health check versehentlich failed? Dann gibt es kein Backup mehr, weil das check failed?
- Es geht das Backup tool auch nix an, ob das Ziel erreichbar ist oder nicht. Das Backup soll einfach versucht werden, wenn das Ziel nicht erreichbar ist, schlägt es fehl und löst Konsequenzen wie alarmierung aus. Dein Script hingegen checked den online Status mittels Ping. Ping ist ICMP. ICMP wird von fast allen per default geblockt. Dein script meint also immer, das Ziel wäre offline.
Weiter habe ich gar nicht erst gelesen.
Weiterer Kritikpunkt: Beschreib doch bitte mal zuerst was dein Tool können soll, wozu es da ist, und wie es das macht. Zum Beispiel so:
Dann kann sich jemand der auf PBS schwört vielleicht schon mal sagen, "das ist nicht mein use case, da bin ich raus" und muss gar nicht weiter lesen.
Wenn du jetzt meine sachliche Kritik als "AI Hate" abtun möchtest, feel free.
KI ist halt echt eine Dunning Kruger Machine.
Ist nett gemeint Kleiner, aber glaube niemand hat hier interesse an einem Backup KI Slop von jemandem, der noch nicht mal weiss, wie er 4 Dateien auf Github teilt.
Nur mal so als kleiner Input, warum dein Script strunzdumm ist:
- Ob der Quell Pool gesund ist, geht ein Backup tool nix an. Was wenn dieser health check versehentlich failed? Dann gibt es kein Backup mehr, weil das check failed?
- Es geht das Backup tool auch nix an, ob das Ziel erreichbar ist oder nicht. Das Backup soll einfach versucht werden, wenn das Ziel nicht erreichbar ist, schlägt es fehl und löst Konsequenzen wie alarmierung aus. Dein Script hingegen checked den online Status mittels Ping. Ping ist ICMP. ICMP wird von fast allen per default geblockt. Dein script meint also immer, das Ziel wäre offline.
Weiter habe ich gar nicht erst gelesen.
Weiterer Kritikpunkt: Beschreib doch bitte mal zuerst was dein Tool können soll, wozu es da ist, und wie es das macht. Zum Beispiel so:
Dann kann sich jemand der auf PBS schwört vielleicht schon mal sagen, "das ist nicht mein use case, da bin ich raus" und muss gar nicht weiter lesen.
Wenn du jetzt meine sachliche Kritik als "AI Hate" abtun möchtest, feel free.
Last edited:
Ohne jetzt noch gross auf die Diskussion „KI gut oder böse” einzugehen, hier nur eine Zusatzinfo für alle, die auf diesen Thread stossen, weil sie ZFS-Snapshots/Replikation machen wollen. Vielleicht ist es ja auch hilfreich für dich, @hackmann
Sanoid/Synchoid existiert. Ich bin kein Experte, wenn es darum geht, den Code von Sanoid oder deinen zu beurteilen. Sanoid gibt es aber schon seit Jahren, es ist sogar in den Debian-Repositories enthalten und kann somit auch über apt installiert werden (allerdings von dort nicht in der neuesten Version). Meiner Meinung nach ist es doch einiges ausgeklügelter als dein KI-Experiment, soweit ich es mit meinen sehr begrenzten Programmierkenntnissen beurteilen kann. Was ich definitiv sagen kann, ist, dass ich es seit Jahren nutze (nur den Snapshot-Teil ohne Replikationen) und es absolut zuverlässig und unauffällig im Hintergrund läuft. Ich habe auch schon Snapshots, die damit erstellt wurden, zurückgerollt oder geklont, und das hat immer einwandfrei funktioniert.
Also, liebe A.I.-Fans und Vibecoder: Schaut euch doch auch mal an, was es da draussen bereits alles gibt, bevor ihr versucht, das Rad neu zu erfinden, und es dann auf die Öffentlichkeit loslasst bzw. von dieser prüfen lassen wollt.
Sanoid/Synchoid existiert. Ich bin kein Experte, wenn es darum geht, den Code von Sanoid oder deinen zu beurteilen. Sanoid gibt es aber schon seit Jahren, es ist sogar in den Debian-Repositories enthalten und kann somit auch über apt installiert werden (allerdings von dort nicht in der neuesten Version). Meiner Meinung nach ist es doch einiges ausgeklügelter als dein KI-Experiment, soweit ich es mit meinen sehr begrenzten Programmierkenntnissen beurteilen kann. Was ich definitiv sagen kann, ist, dass ich es seit Jahren nutze (nur den Snapshot-Teil ohne Replikationen) und es absolut zuverlässig und unauffällig im Hintergrund läuft. Ich habe auch schon Snapshots, die damit erstellt wurden, zurückgerollt oder geklont, und das hat immer einwandfrei funktioniert.
Also, liebe A.I.-Fans und Vibecoder: Schaut euch doch auch mal an, was es da draussen bereits alles gibt, bevor ihr versucht, das Rad neu zu erfinden, und es dann auf die Öffentlichkeit loslasst bzw. von dieser prüfen lassen wollt.
Last edited:
Andere Optionen:
- zfs-auto-snapshots, das nutze ich gerade, lässt sich auch mit apt unter Debian installieren, da hat @fireon mal ein nettes Tutorial zu gepostet:
- cv4pve-autosnap erstellt auch automatisch Snapshots für die VMs und Container: https://github.com/Corsinvest/cv4pve-autosnap Das klingt sehr praktisch, weil man diese Snapshots dann ja auch direkt über das Webinterface zum Zurückrollen nutzen kann.
ich nutze zfs-auto-snapshots und c4pve-autosnap parallel, c4pve-autosnap für meine VMs und Kontainer und zfs-auto-snapshots für meine Datasets
man kommt damit sehr schnell an ältere Daten falls man diese mal benötigen sollte
man kommt damit sehr schnell an ältere Daten falls man diese mal benötigen sollte
Na wenigstens scheint die Ausgabe schön bunt zu sein.
Womöglich bekommen wir noch ein script für die Rücksicherung geliefert, bevor der KI-Apologet erkennt, dass ein PBS sein (vermutetes) Ansinnen bereits erheblich eleganter abbildet.
Womöglich bekommen wir noch ein script für die Rücksicherung geliefert, bevor der KI-Apologet erkennt, dass ein PBS sein (vermutetes) Ansinnen bereits erheblich eleganter abbildet.
Last edited:
Naja, grundsätzlich haben ZFS-Snapshots und -Replikation schon ihre Berechtigung. Wobei ich die Replikation auch nicht nutze, da ich, vzdump und mittlerweile für einige Maschinen auch noch Proxmox Backup Server für die eigentlichen Backups verwende.
Der Vorteil von ZFS-Snapshots ist, dass man innerhalb einer Sekunde zurückrollen kann. Ausserdem kann man ZFS Snapshots klonen und mounten, umd dann auf einzelne Dateien zugreifen oder die geklonte Disk als separate VM starten.
Die Vorteile der ZFS-Replikation sind, dass sie mit jedem ZFS-System funktioniert, Push oder Pull unterstützt und das alles auch auf langsamem „Spinning Rust“. Für den Proxmox Backup Server braucht man halt, nun ja, einen Proxmox Backup Server.
Der Nachteil von ZFS-Snapshots ist, dass die Maschine nicht „aware“ ist was passiert. Sprich: Wenn du auf einen ZFS Snapshot zurückrollst, befindet sich das Betriebssystem in einem Zustand, als hättest du bei einer physischen Maschine einfach den Stecker gezogen. Bei mir hat das allerdings noch nie Probleme gemacht.
Last edited:
Klar. ZFS-snapshots haben auch ihre Daseinsberechtigung. Die Dinger lassen ja ein schnelles Rollback zu. Tools dafür bringt ZFS ja von Haus aus mit. Ich bin aber noch nie auf die Idee gekommen, diese irgendwohin zu replizieren.
Woher also der Wunsch, hier etwas Schwindliges rumscripten zu lassen?
Woher also der Wunsch, hier etwas Schwindliges rumscripten zu lassen?
Nun, wenn du sie irgendwohin replizierst, hast du auch gleich ein Backup. Wenn du sie von irgendwo pullst, hast du sogar immutable Backups.
Aber ja, im Falle von Proxmox VE würde ich auch eher PBS oder zumindest regelmässige vzdumps empfehlen, für Firmen sowieso, nur schon wegen des offiziellen Supports.
Grundsätzlich ist aber eine Replikation der ZFS-Snapshots durchaus als Backup geeignet. Die Frage ist hier eher (wenn man diesen Weg gehen will), ob man nicht besser auf bewährte Lösungen zurückgreifen sollte, anstatt sich etwas zu vibecoden.
Last edited:
Natürlich kann ich KVM oder LXC ganz ohne PVE nutzen. ZFS bekomme ich auch zu Fuß geregelt.
Warum sollte ich aber das Rad zweimal erfinden bzw. von einer KI erfinden lassen?
Warum stelle ich meine KI-Ergüsse bzgl. heiklen Umgebungen dann in das Proxmoxforum?
P.S:
Ich habe z.B lange ein kleines, grundsolides Tool namens zbackup (http://zbackup.org/) verwendet. Inzwischen aber aus der Zeit gefallen. PBS kann alles in schick und effizenter.
Allerdings fehlen auch da Dinge, die Novell schon konnte.
So hätte ich z.B. bei der Einzeldateiwiederstellung mittels PBS gerne eine Liste der verfügbaren Versionen.
Last edited:
Proxmox Backup Server kann z. B. kein Pull-Backup. Du brauchst also einen zweiten Proxmox Backup Server. Gut, den braucht man sowieso, wenn man die 3-2-1-Regel wirklich umsetzen will. Und ja, Proxmox Backup Server ist cool. Aber Homelabber haben in der Regel eben nicht mindestens drei Server an zwei Standorten.
Im besten Fall haben sie zwei Maschinen: Eine davon ist Proxmox VE (und nein, drei Mini-PCs in einem Cluster zählen backuptechnisch immer noch als eine Maschine) und die zweite Maschine entspricht in der Regel auch nicht annähernd den offiziellen Anforderungen für einen Proxmox Backup Server.
Ist diese zweite Maschine z. B. ein TrueNAS, warum sollte man dann nicht einfach die Snapshots dorthin replizieren? Das spart gegenüber VZDumps Plattenplatz.
Klar, die andere Möglichkeit wäre, auf diesem TrueNAS einen Proxmox Backup Server als Container oder VM zu installieren. Aber das ist dann halt so ein unsupportetes Konstrukt. Und wenn dieses Konstrukt die „dirty bitmaps“ irgendwie durcheinanderbringt, ist Ende Gelände.
ZFS hingegen ist extrem resilient. Da musst du schon ziemlich grosse Stunts machen, um es kaputtzukriegen. Wenn dein NAS abraucht, musst du nur irgendwo ein Mainboard mit genug SATA-Anschlüssen finden, die Platten anschliessen und mit einem zfs import bist du wieder im Spiel.
Bei einem Proxmox Backup Server musst du erst einmal wieder einen PBS zum Laufen bringen, dann deinen Pool importieren oder, oder falls du nicht ZFS nutzt dein RAID wieder funktionstüchtig kriegen, und anschließend den neuen PBS wieder in deinem Proxmox VE bekannt machen.
Versteh mich nicht falsch: Proxmox Backup Server ist cool. Aber meiner Meinung nach hat Proxmox hier auch ein Stück weit das Rad neu erfunden. Ich hätte mir gewünscht, dass man stattdessen etwas auf Basis von ZFS gebaut hätte, das sich direkt in die Oberfläche von Proxmox VE integriert, anstatt etwas „Proprietäres“ zu schaffen. „Proprietär“ im Sinne von: Es funktioniert nur im Proxmox-Universum, nicht im Sinne von Closed Source.
Last edited:
Dafür funktioniert es unabhängig vom Dateisystem, ZFS ist eben ( leider ) nicht überall vorhanden. Der PBS funktioniert auch mit HW-RAID, externen Laufwerken oder Magnetbändern
Eine Appliance könnte das natürlich auch vorschreiben.
Aber ja, ich sehe deinen Punkt. Am Ende des Tages sind das Enterprise-Produkte, und in diesem Kontext ergibt Proxmox Backup Server absolut Sinn.
Für Homeuser bzw. Homelabs bin ich mir hingegen nach wie vor nicht sicher, ob man sich ausschliesslich darauf verlassen sollte, wenn man nicht wenigstens eine dedizierte Maschine hat, die den offiziellen Anforderungen zumindest halbwegs gerecht wird.
Wenn ich Konstrukte sehe, die Homelabber so machen, wie einen Proxmox Backup Server-Container oder eine VM auf Proxmox VE mit einem NFS-Share auf einer Synology DSM, oder andern NAS Systemen, oder Containern oder VMs auf NAS-Systemen, sehe ich das eher kritisch.
Einen klassischen VZDump kannst du im Zweifel immer irgendwie wiederherstellen. Und ein ZFS raw Dataset kannst du im Prinzip sogar einfach direkt wieder verwenden. Bei einem verschachtelten PBS-Setup bist du im Notfall dagegen darauf angewiesen, erst einmal genau dieses Setup wieder funktionsfähig zu bekommen.
Last edited:
Aber Homeuser sind auch nicht wirklich die Zielgruppe. Ich finde es schon legitim dass in den Scope einfließen zu lassen bei der Architektur
Warum bei einem PBS ZFS nicht die Basis sein kann hat @johannes schon dargelegt.
Nebenbei frage ich mich, wer sich eine reliable Scriptlösung antun möchte, mit verify, gc und retention und das alles mit komfortablen Rücksicherungsmöglichkeiten.
Ich habe auch lange gebraucht mich auf PBS wirklich einzulassen. Vorher habe ich mit dem von mir bereits erwähnten zbackup und den dazu passenden Scripten gearbeitet. Geht mit Inhalten von Dateiservern fast perfekt. Mit schnöden Dumps schon aufgrund des Namenskozepts eher weniger. Jetzt verfahre ich wie folgt:
Nebenbei frage ich mich, wer sich eine reliable Scriptlösung antun möchte, mit verify, gc und retention und das alles mit komfortablen Rücksicherungsmöglichkeiten.
Ich habe auch lange gebraucht mich auf PBS wirklich einzulassen. Vorher habe ich mit dem von mir bereits erwähnten zbackup und den dazu passenden Scripten gearbeitet. Geht mit Inhalten von Dateiservern fast perfekt. Mit schnöden Dumps schon aufgrund des Namenskozepts eher weniger. Jetzt verfahre ich wie folgt:
- PBS als komplette VM auf einer dicken USB-Platte
- Pull-PBS an anderer Stelle, sogar mit lahmarschigen Verbindungen
- Beides funktioniert im Tagesbetrieb rattenschnell
- Zahnschmerzen bekommt man erst, wenn man Daten vom Pull-PBS zurückspielen will
- ZFS löst das aber auch in keinster Weise.
- Parallel sichere ich noch mit vzdump mindestens 2 Versionen auf Wechselmedien um Zahnschmerzen so spät wie möglich zu bekommen.
- Ordentliche und verlässliche Einbindung von USB-Medien per WebGUI
- eine Option für PVE, darauf die letzte Dumpversionen ablegen zu können.
- Und Tadaa, das ganze per solidasarock-rsync statt stumpfen Kopierens und anschließendem Löschen der abgelaufenen Version und auch das geht dann rattenschnell.
Last edited:
Da wäre dann halt eine Lösung von Proxmox basierend auf ZFS cool.
Wieso? Das ist am Ende einfach eine umgekehrte Replikation? Aber ja, via GUI ist dann natürlich nichts, und die VM Config wird auch nicht mitgesichert. Darum siehe oben.
Und bei einem Restore löst beides natürlich noch ein anderes Problem nicht: Beim Zurückspielen muss, egal ob bei ZFS-Repplikation, VZdump oder Proxmox Backup Server, immer die gesamte Datenmenge wieder zurückkopiert werden. Das heisst, es dauert unter Umständen ewig, und von möglichen „Egress Fees“ bei Offsite-Backups reden wir lieber gar nicht.
Aber ja, "I get it". Und nichts gegen PBS oder Proxmox im Allgemeinen. Ich denke hier nur laut
Last edited:
Stören würde mich eine integriert ZFS-Lösung natürlich auch keinesfalls. Steht aber auf der PROXMOX-Agenda wohl ziemlich weit unten.Da wäre dann halt eine Lösung von Proxmox basierend auf ZFS cool.
Wieso? Das ist am Ende einfach eine umgekehrte Replikation? Aber ja, via GUI ist dann natürlich nichts, und die VM Config wird auch nicht mitgesichert. Darum siehe oben.
Und wenn du Offsite-Backups meinst, löst das natürlich noch ein anderes Problem nicht. Denn beim Zurückspielen muss natürlich immer, egal ob ZFS Snapshots oder PBS, die gesammte Datenmenge wieder zurückkopiert werden. Das heisst, es dauert unter Umständen ewig, und von allfälligen "Egress-Fees", reden wir lieber gar nicht.
Aber ja, "I get it". Und nichts gegen PBS oder Proxmox im Allgemeinen. Ich denke hier nur laut
Ich bin völlig bei dir und ein forum ist schließlich zum lauten Denken da.
So denke ich, dass PROXMOX den Restorevorgang viel zuwenig auf dem Schirm hat und leider Dinge voraussetzt, die häufig nicht gegeben sind.
Betrachtet man Restore dann:
- Dann probiere ich erst meine übliche lokal vorhanden PBS-Sicherungen
- Da der PBS komplett auf einem externen Datenträger "wohnt", stöpsel ich diesen bei Ausfall des Hosts an einen anderen PVE, der die PBS-Konfiguration schon kennt und starte dort den PBS.
- Danach probiere ich weitere lokal vorhandene Sicherungsmedien.
- Danach einen Pull-PBS
- Bin ich mit 1GBit+ angebunden, bin ich froh.
- Leider kenne ich genügend Standorte, bei dem diese Bandbreite nur im Traum existieren.
- Jetzt denke ich darüber nach die Daten am Remotestandort auf einen Datenträger zu ziehen und per Post zu verschicken, statt auf x-TB per Leitung zu warten.
- Da wären relativ kleine und günstige Wechselmedien, auf die lokal mindestens die letzte Sicherung von VMs liegen, schon sehr nett.
Last edited:
Da haben wir unterschiedliche Ansichten über die 3-2-1 Regel.
2 Medien kam ja von früher, wie einmal Festplatte einmal Bandlaufwerk.
Einfach nur zwei PBS sind für mich nicht zwei Medien.
VZDump auf eine externe Festplatte, plus remote PBS ist für mich 3-2-1.
Oder PBS + zfs send.
Oder halt noch besser, die moderne 3-2-1-1-0 Regel. Zusätzlich ist ein target immutable (gut machbar mit PBS) und 0 Fehler Testen der Wiederherstellung (auch gut machbar mit PBS).