Hi Leute,
hier findet ihr einen von mir neu entwickelten Workflow.
Er richtet sich momentan an Systeme mit einem Datastore mit ZFS und einem z. B. alten Replicaserver der die meiste Zeit aus ist.
Beste Verteidigung, nicht da sein
https://github.com/bashclub/miyagi-pbs-zfs/tree/dev
Wofür ist es gedacht
Proxmox Backupserver rennt die meiste Zeit durch und wartet auf Backups von PVEs, was in meinen Augen keinen Sinn macht.
In dieser Zeit frisst er Strom und wäre theoretisch angreifbar.
ZFS Replikate auf PVE sind Push Replikationen und können bei kompromitierten Systemen einfach entfernt und gelöscht werden.
Eine Zeitauswahl von Snapshots ist nicht gegeben.
Wenn der Backupserver/Replicaserver aber die meiste Zeit aus ist, frisst er keinen Strom und ist nicht angreifbar.
Was passiert nun.
Wir starten das System per Wakeonlan mit einem Cronjob @reboot für unser Skript.
Danch ziehen wir alle Datasets/ZVOLS unterhalb vom ZFS-Datastore (z. B. rpool/data) und nutzen unser checkzfs-tool für einen zweifelsfreien Report und schieben diesen in ein Check_MK System auf dem Quellserver.
Je nach Wochentag führen wir ein per ssh gestartetes Proxmox Backup auf den PBS aus und mittels Exitcode erzeugen wir einen kompakten Report für Check_MK und schieben diesen direkt auf den Quellserver.
Danach steuern wir noch Garbage Collection, Prune und Verify je nach Wochentag.
Am Ende sichern wir alle Backups mit einem daily Snapshot ab.
Wir nutzen unsere eigenen Tools plus zfs-auto-snapshot
proxmox-zfs-postinstall für Tools und Autosnapshot (Zielserver soll z. B. 5 Tage erhalten)
zamba-lxc-toolbox für die installation von Proxmox Backupserver als LXC
check-zfs-replication für die Prüfung der Snapshots auf Quelle und Ziel via GUID
Näheres im Video vom YouTube Kanal sysops.tv vom 20.11.2023
https://www.youtube.com/watch?v=Eqh7goDV1Uc
Über konstrukive Kritik würde ich mich freuen
LG
chriz
hier findet ihr einen von mir neu entwickelten Workflow.
Er richtet sich momentan an Systeme mit einem Datastore mit ZFS und einem z. B. alten Replicaserver der die meiste Zeit aus ist.
Beste Verteidigung, nicht da sein
https://github.com/bashclub/miyagi-pbs-zfs/tree/dev
Wofür ist es gedacht
Proxmox Backupserver rennt die meiste Zeit durch und wartet auf Backups von PVEs, was in meinen Augen keinen Sinn macht.
In dieser Zeit frisst er Strom und wäre theoretisch angreifbar.
ZFS Replikate auf PVE sind Push Replikationen und können bei kompromitierten Systemen einfach entfernt und gelöscht werden.
Eine Zeitauswahl von Snapshots ist nicht gegeben.
Wenn der Backupserver/Replicaserver aber die meiste Zeit aus ist, frisst er keinen Strom und ist nicht angreifbar.
Was passiert nun.
Wir starten das System per Wakeonlan mit einem Cronjob @reboot für unser Skript.
Danch ziehen wir alle Datasets/ZVOLS unterhalb vom ZFS-Datastore (z. B. rpool/data) und nutzen unser checkzfs-tool für einen zweifelsfreien Report und schieben diesen in ein Check_MK System auf dem Quellserver.
Je nach Wochentag führen wir ein per ssh gestartetes Proxmox Backup auf den PBS aus und mittels Exitcode erzeugen wir einen kompakten Report für Check_MK und schieben diesen direkt auf den Quellserver.
Danach steuern wir noch Garbage Collection, Prune und Verify je nach Wochentag.
Am Ende sichern wir alle Backups mit einem daily Snapshot ab.
Wir nutzen unsere eigenen Tools plus zfs-auto-snapshot
proxmox-zfs-postinstall für Tools und Autosnapshot (Zielserver soll z. B. 5 Tage erhalten)
zamba-lxc-toolbox für die installation von Proxmox Backupserver als LXC
check-zfs-replication für die Prüfung der Snapshots auf Quelle und Ziel via GUID
Näheres im Video vom YouTube Kanal sysops.tv vom 20.11.2023
https://www.youtube.com/watch?v=Eqh7goDV1Uc
Über konstrukive Kritik würde ich mich freuen
LG
chriz