Danke das ist auf jeden Fall noch ein guter Hinweis, dass es auch noch sowas gibt, ist mir irgendwie durchgerutscht.
Der Witz beim special device ist halt, dass die Metadaten neu geschriebener Daten dann (solange Platz da ist) auf das special device ausgelagert werden. Rein theoretisch könnte man auch ein hdd dafür nehmen, aber dann hat man natürlich keinen Performance-Vorteil. Profitieren tun davon alle Sachen, die vor allen mit den Metadaten arbeiten, aber nicht die eigentlichen Daten (z.B. um Dateien samt Größen in einen Verzeichnis aufzulisten). Das macht sich besonders bemerkbar, wenn der Datenspeicher für z.B. PBS (oder ähnlich arbeitende Software) auf HDDs liegt. Es hat ja seine Gründe, warum die PBS-Doku dafür explizit Enterprise-SSDs empfiehlt. Wenn die aber keine Option sind, sorgt das special device dafür, dass die garbage collection und verify immer noch langsamer sind als mit SSDs, aber wenigstens in einer halbwegs vertretbaren Zeit fertig wird. Bei der Garbage Collection ist der Effekt am Stärksten, da diese Jobs hauptsächlich mit den Metadaten arbeiten, während die verify-Jobs auch die eigentlichen Daten einlesen müssen (die ja trotzdem auf den HDDs liegen). Nachteil wie gesagt: Ist das special device kaputt, sind auch die Daten auf den hdds weg.
Reicht es als Privatanwender nicht auch zpool scrub wöchtenlich zu verwenden und im Notfall Snapshots parat zu haben oder schieße ich mir damit ins eigene Bein und sollte wirklich auf die autoheal funktion setzen?
Nein, das scrub erkennt zwar die Fehler, kann sie mit den Standardeinstellungen aber nicht "reparieren". Die kann man zwar ändern (so dass auch bei nur einen Laufwerk dort zwei Kopien der Daten vorgehalten werden), aber das frisst dann natürlich auch mehr Platz. Und wenn die Platte selbst kaputt ist, nützt das einen auch nichts (anders als bei einen richtigen Mirror mit zwei getrennten Laufwerken):
https://docs.oracle.com/cd/E19253-01/820-2313/gevpg/index.html
Bei Snapshot meinst du hoffentlich vom medium her getrennte Backups oder? Auf den potentiell defekten gleichen Laufwerk nützen die dir ja nichts. zfs hat mit zfs send/receive eine ganz praktische Funktion, um die lokalen Snapshots auf externe Medien oder Server zu replizieren, damit hätte man dann das Backup. Oder man macht halt ein Backup des Hosts mit einen klassischen Backuptool (ich nehme restic dafür, da ich dann für die Wiederherstellung des Hosts keinen laufenden ProxmoxBackupServer benötigte, andere Leute sind mit borgbackup oder dem proxmox-backup-client +PBS glücklich, ist wie immer Abwägungssache).
Leider nicht, ich habe mich dazu entschieden diesen Tod zu sterben und hab aus kostengründen auf ECC verzichtet, weil ich dann auch wieder auf eine teurere AM4 Plattform wechseln müsste, die dann am Ende nicht die nötigen Transcoding Funktionen hat, die ich brauche und da noch ein riesiger Rattenschwanz dran gehangen hätte. Am Ende des Tages bin ich auch einfach nur ein Student, der sich in einer Freizeit da ein bisschen ausprobieren möchte, ohne das Budget komplett zu sprengen.
Gibt auch X86-Mainboards mit ECC-RAM
Aber ja ich verstehe das, am Ende ist es bei mir im Homelab ja nicht anders, was Usecase und Budget angeht. Sollte ich aber doch mir mal einen NAS-Server selbst aufsetzen, würde ich dafür dann wohl was mit ECC machen.
Da bin ich im Originalpost nicht drauf eingegangen, weil das sonst den Rahmen etwas gesprengt hätte. Geplant ist PBS in einem LXC laufen zu lassen, um dort nächtlich Backups/Snapshots zu erstellen und diese dann auf eine NAS zu schicken die extern bei meinem Vater liegt. Um das 3-2-1 Backup System auch richtig umgesetzt zu haben, hatte ich überlegt auf LTO-5/6 Tapes weitere circa halbjährliche Backups anzulegen, das ist aber noch Zukunftsmusik da möchte ich erstmal soweit den Server aufgesetzt haben und die NAS Backups reichen dann hoffentlich fürs Erste.
Naja, seit Version 8.3. erlaubt der PBS auch "removable Datastores", also z.B. externe USB-Laufwerke, die sind doch deutlich budgetfreundlicher als Tapes (auch wenn die natürlich mehr streetcreds unter Nerds bringen
) und performanter. Gemeinsamer Nachteil: Man muss ans wechseln/abstecken denken, damit sie bei einen Ransomwareangriff nicht mit verschlüsselt werden.
Zu LXC: Das wird offiziell nicht unterstützt, da man dann ja kein unabhängiges Backup vom Host hat. Beschrieben aber (aus gleichen Grund von abgeraten) wird die Installation direkt auf dem Host:
https://pbs.proxmox.com/docs/installation.html#install-proxmox-backup-server-on-proxmox-ve
Ich selbst arbeite mit einer PBS-VM, deren Backups ich zusätzlich auf einen PBS auf einen vserver und eine externe Platte repliziere. Zusätzlich mache ich von den wichtigsten LXCs/VMs ein wöchentliches vzdump-Backup mit der nativen Funktion von PVE auf einen Cloudspeicher, um notfalls auch ohne PBS noch ein (älteres) Backup zu haben. Die dabei erzeugten vma-Archive brauchen zum Backup- und Restore keinen laufenden PBS, nehmen aber dafür in der Summe deutlich mehr Platz weg, da sie immer alle Daten sichern und kein inkrementelles Backup erlauben.
Das mit der Replikation auf ein offsite-NAS ist grundsätzlich eine gute Idee, ich würde dafür dort aber (falls das NAS das unterstützt) auf der NAS eine PBS-VM anlegen, um direkt die native sync-Funktion von PBS nutzen zu können ("remote datastores"). Falls deine Uni einen Cloudspeicher für Studis anbietet, wäre der sonst auch noch eine mögliche Variante (und sei es nur für seltener gesicherte vmas als zusätzliche Absicherung).
Die 3-2-1-Strategie kennst du, also dass man neben drei Kopiem (Produktivdaten + zwei Backups) auf mindestens zwei verschiedenen Medien und wenigstens eine davon offsite vorhalten sollte?
Macht es dann überhaupt Sinn, wenn ich nur ein Bootlaufwerk habe (Der Spiegel wird wohl aus Platz und Kostengründen nix
) das mit ZFS als Dateisystem laufen zu lassen oder sollte ich das besser einfach auf ext4 oder ähnlichem laufen lassen was nicht so schreiblastig ist wie ZFS?
ZFS hat außer RAID noch genug eigene Vorteile, da muss man abwägen, ob die einen das wert sind (Kompression auf Dateisystemebene, Replikation, Fehlererkennung...)
Grundsätzlich könntest du auch erstmal mit nur einen Laufwerk als Bootdevice anfangen und das später zum spiegel erweitern, dazu gab es mal was hier im Forum. Ich habe das aber bisher auch nicht und als todo bei "genug Geld über" eingeplant. Bei meinen mini-PCs ist das Problem, dass da teilweise gar nicht der Platz da ist, bzw. man da tricksen/frickeln muss. Im Homelab akzeptabel, auf der Arbeit (bin Sysadmin) würde ich das so definitiv nicht machen.
Generell ist es eine gute Idee (wie du es machst) sich im Vorfeld Gedanken darum zu machen, was man eigentlich erreichen will und die dafür am wenigsten schmerzende Konfiguration zu entwerfen, statt einfach draufloszubasteln. In der Umsetzung werden sich dann noch Sachen ändern, aber dann weiß man wenigstens schon, wo man hinwill
