Post by Alexander GoetzensteinPost by Marcel MuellerDie Größe der Dateien _sollte_ bei einem inkrementellen Backup egal
sein. Normalerweise werden nur die Metadaten gewälzt, um zu entscheiden,
was gesichert werden soll. Das kann aber bei _sehr vielen_ Dateien und
konventionellen Festplatten auch schon erkleckliche Zeit dauern.
mir deucht, dass bei der Datensicherung die Quelldaten noch einmal
durchforstet werden, ob etwas neu zu sichern dabei ist. Das geht zwar um
Größenordnungen schneller (die erste Komplettsicherung hat >1.000h
Ach herrje. Ich würde sagen der Durchsatz des Backupverfahrens ist
schlicht der Datenmenge nicht gewachsen.
Post by Alexander Goetzensteingedauert), dauert aber für den täglichen Betrieb dennoch zu lange.
Effektiv nutzbare Betriebspause ist derzeit 6h täglich, die Sicherung
braucht das doppelte.
Für /dieses/ Problem können Snaps tatsächlich die Lösung sein. Aber wenn
es irgendwann 24h dauert, hilft das natürlich auch nicht mehr.
Post by Alexander GoetzensteinPost by Marcel MuellerPost by Alexander Goetzenstein2.
Falls ich bei der Einrichtung EXT4 gewählt haben sollte: wie kann ich es
in BTRFS konvertieren?
Nein.
Löschen und neu bespielen heißt die Konvertierung.
Ich hab's befürchtet. Hätte ja sein können, dass es ein Tool für eine
Online-Konvertierung o.ä. gibt.
Nicht wirklich. Die Dateisysteme verwenden komplett unterschiedliche
Datenstrukturen auf dem Datenträger.
Nur für sehr ähnliche Systeme wie ext2/3/4 gab es das. Aber selbst da
war das Ergebnis suboptimal, vor allem weil ext2/3 keine brauchbaren
Datenstrukturen für die Speicherung sehr großer Dateien hatten.
Post by Alexander GoetzensteinPost by Marcel MuellerPost by Alexander Goetzenstein3.
Laut Synology Knowledgebase sind maximal 256 Snapshots möglich. Das
reicht bei täglicher Nutzung nicht weit. Wie geht man damit um?
Wenn du einen Snap nicht mehr brauchst kann er weg. Das ist auch
wichtig, denn da Dateisystem müsste ja sonst auch alle Daten von damals
auf ewig speichern. Ein Snap ist logisch gesehen ein Vollbackup, nur
eben ohne anderen Datenträger, was entsprechend nur gegen einige
Fehlerszenarien schützt.> Üblicherweise kann der Snap direkt nach dem Backup wieder weg.
"Weg" heißt, er wird sozusagen in den Snap #0 integriert, oder wie muss
ich mir das vorstellen?
Nein, der wird einfach gelöscht.
Das sind keine Block-Device Snaps wie bei VMs. Ein Snap ist in erster
Näherung ein Reflink auf das Root-Verzeichnis und alles darunter. Und
jede nachfolgende Änderung triggert CopyOnWrite, die geänderten Daten
einschließlich Verzeichniseinträgen werden also einfach an eine andere
Stelle auf dem Datenträger geschrieben. Primär wird also die Freigabe
der im Haupt-Volume nicht mehr benötigten Blöcke verhindert. Das löschen
des Snaps gibt die Bereiche dann wieder frei, sofern sie nicht noch von
einem anderen Snap oder im Haupt-Volume gebraucht werden.
Post by Alexander GoetzensteinPost by Marcel MuellerGenau da setzen die Snaps an. Die stellen zwar auch keine 100%
Datenkonsistenz sicher, denn Anwendungen haben ja Dateien geöffnet, aber
das Zeitfenster ist um Größenordnungen kleiner. Ein Snap ist wie ein
Stromausfall. Er spiegelt den aktuell persistierten Stand des Systems
wieder. Wenn er auf Dateisystemebene erfolgt ist er sogar noch etwas
besser, denn er berücksichtigt auch noch im Write-Back-Cache liegende Daten.
BTW: wie werden dabei gelöschte Dateien gehandhabt? Enthält der Snap
dann so etwas wie einen negativen Dateieintrag, oder wie läuft das ab?
Nein, der Snap enthält das alte Verzeichnis, wo die Datei noch
existiert. Es gibt kein diff. Eigentlich ist es nur die
Weiterentwicklung von RefLinks auf Verzeichnisebene.
Post by Alexander GoetzensteinPost by Marcel MuellerPost by Alexander Goetzenstein4. Die Fragen 2. und 3. stellen sich bei dem per iSCSI von einem
Linux-Server genutzten "Laufwerk", nur eben nicht mit
Synology-Werkzeugen, sondern von Linux aus.
iSCSI ist immer noch ein Disc-Device, nur dass es nicht lokal eingebaut
ist. Das ändert genau gar nichts.
Eines schon: die Handhabung. Bei Synology habe ich das DSM mit seiner
Oberfläche und Tools, bei Linux dafür andere und vermutlich mehr und
ausgefeiltere.
Andres OS, andere Tools. Das war schon immer so. Mit iSCSI hat das nicht
wirklich etwas zu tun.
Post by Alexander GoetzensteinOder umgekehrt. Da wären Hinweise auf die Tools, über die
ich mich belesen sollte, hilfreich. Bislang -man merkt es vermutlich-
bin ich in dem Thema noch ziemlich unbeleckt und suche den Überblick und
Anfang.
iSCSI ist vor allem eines: riskant. Wenn das Netzwerk nur einmal hustet,
entstehen Fehler die mit einem Festplattenausfall vergleichbar sind. Die
können kaum sinnvoll behandelt werden. Und von diesen Fehlern ist es
nicht sonderlich weit zur Kernel-Panic, zumindest wenn wichtige Sachen
wie swap darauf liegen. Die Profis haben deshalb üblicherweise eine
komplett unabhängige Netzwerkinfrastruktur für Storage.
In der Amateur-Klasse würde ich immer versuchen, alle Dateisysteme lokal
zu halten und auf die Daten über höhere Protokollebenen wie NFS oder
Samba zuzugreifen.
Post by Alexander GoetzensteinPost by Marcel MuellerPost by Alexander GoetzensteinOder bin ich hier komplett auf dem Holzweg?
Nein, aber mir drängt sich auch nicht auf, wie das dein Problem mit den
lahmen, inkrementellen Backups lösen sollte. Selbst wenn du den Snap vom
letzten Backup noch hättest, müsste man trotzdem alle Dateien checken,
um herauszufinden, welche neu gesichert werden müssen.
Meine Vorstellung wäre, dann eben jeweils nur den letzten Snap zu
sichern. Da das deutlich weniger Datenmenge ist, sollte das dann schnell
gehen.
Der Snap ist exakt so groß wie dein zu sicherndes Volume zum Zeitpunkt
des Snaps. Physikalisch belegt er nur deshalb weniger Platz auf dem
Datenträger, weil er sich viele, unveränderte Blöcke mit dem Hauptvolume
teilt.
Die Sicherung nur der veränderten Daten macht ja bereits das
inkrementelle Backup. Nur wenn ein Vollbackup 1½ Monate dauert, ist es
kaum verwunderlich, dass auch die täglichen Änderungen mal einen halben
Tag brauchen. Du brauchst einfach mehr Durchsatz.
Bei meinem Heimserver (der auch Fileserver ist) braucht ein Vollbackup
eher so 4 Stunden. Das ist handhabbar. Ich ziehe die Daten allerdings
auch noch auf eine alte Ultrium-Tape-Library und habe nicht so viele Tera.
Post by Alexander GoetzensteinBei einem Komplett-Restore könnte sich das zwar ins Gegenteil
verkehren, aber das ist mir persönlich noch nie vorgekommen, und
außerdem hat man dann wohl noch ganz andere Probleme und ist froh, es
überhaupt hinzubekommen... ;-)
Noch nie getestet? Dann funktioniert es erfahrungsgemäß auch nicht, weil
irgendeine Kleinigkeit, die aber essentiell ist, fehlt.
Marcel