Inkrementelles Backup der TrueNAS-Daten auf Remote-System

[ma-ce]

Hallo zusammen,

Mein TrueNAS-Core-Server (bare metal) dient hauptsächlich als File-Server und stellt entsprechend Files-Shares zur Verfügung.
Neben den Home- und zentralen Verzeichnissen sind noch unsere Familien-Fotos und -Videos wichtig. Alles andere ist nicht so wichtig (Serien, Filme, Musik, eBooks).
Die wichtigen Daten umfassen knapp 500 GB.

Für mein Heimnetzwerk beschäftige ich mich schon eine ganze Weile mit dem Thema Backup, hab aber noch nicht den richtigen Weg gefunden.
Ich möchte den Inhalt einiger Datasets sinnvoll inkrementell auf einem Remote-Linux-Server (in meinem Netzwerk) sichern.
Die Verwaltung der Backups soll möglichst über ein Web-Interface und nicht nur in der Konsole stattfinden.
Wichtig ist mir aber auch, dass ich im worst case nicht erst tagelang recherchieren muss, um die Daten wieder herzustellen. Unsicherheitsfaktoren sollen dabei möglichst wenige bestehen.

Bisher habe ich über Cloud-Sync-Tasks und nun auch mit rsync-Tasks gesichert. Von TrueNAS aus ist das aber scheinbar nicht mit Bordmitteln inkrementell machbar.
Ich möchte das TrueNAS-System auch nicht über die Konsole großartig umbiegen mit Scripts und CRON-Jobs oder zusätzlicher Software. Das zu verwalten ist mir auch zu aufwendig/komplex und bringt m.E. auch einen erheblichen Unsicherheitsfaktor rein.

Ich betreibe parallel, eher zum Spaß, einen halbwegs potenten PROXMOX-Server. Auf diesem könnte ich als VM oder Container einen Backup-Server aufbauen, der über Netzwerk die Daten hin und her schiebt.
Ggf. könnte ich so auch ein zweites TrueNAS-System aufbauen. Die TrueNAS Replikation scheint aber auch nicht ganz das Richtige für mich zu sein. Zumindest wirkt das Thema recht komplex.

Merkwürdigerweise findet man relativ wenig Infos über Daten-Backup VOM TrueNAS sondern nur zum TrueNAS.
Gefunden habe ich die Kombination bacula mit Webmin-Plugin, welche ich auf dem PROXMOX aufsetzen könnte. Allerdings sind die Infos darüber ca. 5-10 Jahre alt, was mir sagt, dass das kein aktuelles Thema mehr ist (oder doch?).

Daher die Frage: Kann mir jemand einen Hinweis geben, welche Software / Funktion ich mir mal anschauen könnte? Notfalls würde ich auch ein paar Euro in die Hand nehmen (nur einmalig, nicht monatlich).

Danke im Voraus!!

 

[Patrick M. Hausen]

ZFS Snapshots und Replikation sind doch eingebaut, komplett über das UI verwaltbar, und inkrementell. Da braucht es keine Zusatzsoftware. Nur ein Zielsystem mit SSH und ZFS, vorzugsweise natürlich ein zweites TrueNAS, aber normales FreeBSD, Debian, Ubuntu, ... funktioniert genauso.

 

[HoPla]

Ich nutze einen "kleinen" 2. Server mit TrueNAS Scale, der 2x am Tag anspringt und per PULL-Replikation die wichtigsten Snapshots (z.B. die HOURLY'S der Datasets) vom Produktiv-System sichert. Danach schaltet er sich wieder ab. Geht alles mit Bordmitteln und da er 23 Stunden nicht im Netz ist, ist er quasi "unangreifbar".

Mit einem CheckZFS-Script erzeuge ich kurz vor dem Abschalten eine Textdatei, die auf dem Produktivsystem abgelegt wird und in der die Snapshots auf Quelle und Ziel verglichen werden. So kann ich mit einem Klick sehen, ob alles funktioniert hat.

 

[ma-ce]

Das klingt jetzt erst einmal so, als wäre das kein Hexenwerk mit Snapshots und Replikation. Muss ich mich allerdings erst einmal einlesen, da ich mich damit kaum beschäftigt habe. Tatsächlich habe ich auf dem Zielsystem ein ZFS laufen. Wichtig ist halt auch noch, wie ich im Fall der Fälle an die gesicherten Daten rankomme, wenn der TrueNAS, ggf. auch für mehrere Tage oder sogar länger, ausfällt.

 

[Patrick M. Hausen]

Wichtig ist halt auch noch, wie ich im Fall der Fälle an die gesicherten Daten rankomme, wenn der TrueNAS, ggf. auch für mehrere Tage oder sogar länger, ausfällt.

SFTP geht immer. Grafischen Client dafür besorgen und gut ist.

 

[bic]

Hmmm, eine Replikation auf eine zweite Truenas betreibe ich auch, nur ist dies zumindest nach meiner unmaßgeblichen Meinung kein wirkliches Backup. Ein solches sollte zumindest eine einstellbare Anzahl von Versionen ermöglichen und revisionssicher auf dedizierten Backupmedien, gern auch an einem entfernten Ort sicher. Ich realisiere dies seit Jahren mit der Communityversion von Veeam, welche einmal innerhäusig und ein zweites Mal außerhäusig (per SSH und VPN) gehärtet auf RDX-Medien schreibt. Bei Bedarf kann man dann so auch die Medien aus den Laufwerken nehmen und in einen Tresor sperren

 

[Patrick M. Hausen]

Mein Replikations-Ziel steht an einem komplett anderen Ort und hat 3 Monate Snapshots anstelle der 2 Wochen, die ich hier lokal aufhebe. Inwiefern ist das kein Backup? Snapshots sind read-only und damit sogar revisionssicher.

Du kannst die Snapshot-Lebensdauer ja für Quelle und Ziel einer Replikation komplett unabhängig voneinander einstellen.

 

[bic]

Weil 3 Monate z.B. keine 10 Jahre sind und weil man keine einzelne Files oder Verzeichnisse (und dann auch noch an einen anderen Speicherort) restaurieren kann. Aber ja, wenn es Dir reicht - mir genügt es nicht.

 

[Patrick M. Hausen]

weil man keine einzelne Files oder Verzeichnisse (und dann auch noch an einen anderen Speicherort) restaurieren kann

Doch, kann man. Völlig einfach.

Code:

root@freenas[~]# cd /mnt/hdd/share/medien/.zfs/snapshot
root@freenas[/mnt/hdd/share/medien/.zfs/snapshot]# ls -l
total 8257
drwxr-xr-x  8 nobody  nogroup  8 Jun 14  2022 auto-2024-02-25_22-00
drwxr-xr-x  8 nobody  nogroup  8 Jun 14  2022 auto-2024-02-25_23-00
drwxr-xr-x  8 nobody  nogroup  8 Jun 14  2022 auto-2024-02-26_00-00
drwxr-xr-x  8 nobody  nogroup  8 Jun 14  2022 auto-2024-02-26_01-00
drwxr-xr-x  8 nobody  nogroup  8 Jun 14  2022 auto-2024-02-26_02-00
[...]
root@freenas[/mnt/hdd/share/medien/.zfs/snapshot]# cd auto-2024-03-10_22-00/
root@freenas[...n/.zfs/snapshot/auto-2024-03-10_22-00]# ls -l
total 99
drwxr-xr-x   7 nobody  nogroup  11 Dec 21  2022 Dokus
drwxr-xr-x  14 nobody  nogroup  16 Sep  8  2021 Filme
drwxr-xr-x   8 nobody  nogroup  10 Aug  4  2023 Musik
drwxr-xr-x   2 nobody  nogroup   9 Sep 18  2021 New
drwxr-xr-x  16 nobody  nogroup  19 Jun 23  2019 Old
drwxr-xr-x  13 nobody  nogroup  15 Apr 20  2023 Serien

Alle Dateien und Verzeichnisse einzeln auf dem Stand von heute, 22:00 genau da.

Und was hält dich davon ab, auf dem Ziel so viel Kapazität bereitzustellen, dass es für 10 Jahre reicht? Ich kenne nichts stabileres als einen ZFS-Pool, dessen darunter liegende Hardware (Festplatten) man alle paar Jahre mal tauscht.

Ich habe rund 1000 Kunden-Instanzen, die ich betreue auf rund 100 Servern. Wir machen seit Jahren nichts anderes als ZFS-Replikation. Wobei wir den Hosting-Kunden nur 14 Tage garantieren. Aber wie gesagt, bau einen größeren Pool und heb 10 Jahre auf.

 

[John Doe]

deine anforderung hatte ich auch und bin ebenfalls auf den replication task gekommen.

wenn du einen 2. truenas hast, kannst du dort auch die replizierten snapshots via SMB einbinden und somit zugänglich machen. Also dann z.b. mit dem windows rechner auf die jeweiligen files zugreifen, die du dann haben möchtest.
Das ist meine fallback lösung, wenn ich es nicht mit dem zurückspielen Truenas <- Truenas backup hinbekomme.

 

[bic]

@Patrick M. Hausen, @John Doe - ok, sicher auch eine Möglichkeit, wenn auch nur ein Bruchteil so komfortabel, wie mit einer dedzierten Backup-Software, z.B. Veeam. Außerdem müsste ich dazu wissen, ob dies mit Zvols-Snaphots ebenfalls funktioniert und ob ich diese per iSCSI dann auch einbinden kann. Im Moment suche im mir noch den Wolf, um überhaupt die Snapshots im System der Truenas(e) zu finden.

 

[chuck32]

@Patrick M. Hausen hat dir ja schon eine sehr gute Antwort gegeben. Ich muss sagen ich bin etwas darüber gestolpert, dass du suggerierst replication tasks wären keine gute Methode für Backups. Ich habe ein wenig den Eindruck, dass du dich mit der Thematik ggf. noch einmal intensiver beschäftigst und dann darüber urteilst.

Aus meiner persönlichen Brille kann nicht nachvollziehen, dass das nur einen Bruchteil des Komforts bieten soll, den veeam bietet. Einmal aufgesetzt verrichten die Replication tasks automatisiert ihren Dienst und wenn etwas nicht funktioniert, erhalte ich einen Alarm.
Ich gebe dir Recht, dass das Aufsetzen eventuell nicht ganz so selbst erklärend ist, wenn man von den Standardeinstellungen abweichen möchte, aber ich bin der Meinung dass truenas insgesamt mit einer gewissen Lernkurve verbunden ist, da reiht sich das ganz gut ein.

Ja zvols lassen sich ebenfalls darüber sichern.

Wo hast du denn nach den Snapshots gesucht? Wenn du im Dataset Screen ein Dataset anwählst, werden dir rechts die Snapshots angezeigt bzw. du kannst dich von der Übersicht (Anzahl snapshots etc.) dahin begeben.

 

[ma-ce]

Über Veaam bin ich auch schon gestolpert. Ich werde mal die Replikation und insbesondere den Zugriff auf die Snapshots testen. Muss mich halt noch einlesen. Mein Thema ist, dass ich im Falle eines Ausfalls nicht etliche Stunden oder Tage mit der Wiederherstellung verbringen kann. Das Leben läuft ohne Gnade weiter und der Kunde (meine Familie) kennt keine Geduld ;) Danke für die Hinweise!!

 

[ChrisRJ]

Mein Thema ist, dass ich im Falle eines Ausfalls nicht etliche Stunden oder Tage mit der Wiederherstellung verbringen kann. Das Leben läuft ohne Gnade weiter und der Kunde (meine Familie) kennt keine Geduld ;) Danke für die Hinweise!!

Also wenn Deine Familie im Ernstfall nicht ein paar Stunden warten kann, haben die aus meiner Sicht schon eine etwas komische Erwartungshaltung. Aber bei 500 GB ist die Diskussion eh mehr oder weniger Makulatur. Das ist heute so wenig, dass man auch einfach ein paar alte/kleine USB Platten nehmen und immer alles kopieren kann. Dann durchrotieren und gut ist.

 

[bic]

@Patrick M. Hausen hat dir ja schon eine sehr gute Antwort gegeben. Ich muss sagen ich bin etwas darüber gestolpert, dass du suggerierst replication tasks wären keine gute Methode für Backups. Ich habe ein wenig den Eindruck, dass du dich mit der Thematik ggf. noch einmal intensiver beschäftigst und dann darüber urteilst.

Nun, das kommt darauf an, wie man "Backup" definiert und welchen eigenen Anspruch man daran stellt. Mir jedenfalls dient die replizierte Truenas vor allem als Hot Standby Speicher, welcher dank iSCSI innerhalb von Minuten nach irgendwelchen Ausfällen ins Büronetz eingebunden ist und den Mitarbeitern ermöglicht, ihre Arbeit fortzusetzen - um dies zu realsieren, muss ich noch nicht einmal vor Ort sein. Gern kann man dies auch als "Backup" bezeichnen, ich würde die Sache eher als Spiegelung sehen.

Von einem "Backup" erwarte ich weitere Fähigkeiten, vor allem auch die Möglichkeit, einzelne, versionierte Dateien und Verzeichnisse schnell wiederherstellen zu können, denn man glaubt es kaum, meine Mitarbeiter "zerschießen" dann doch das eine oder andere. Da möchte ich dann nicht z.B. wegen eines einzelnen vergeigten Excelsheets erst (mühselig) Truenassnapshots an irgendeine Windowsmaschine anbinden müssen, sondern per Mausklick in wenigen Minuten das Excelsheets in einer früheren Version meiner Wahl hervorzaubern - genau dies geht z.B. mit Veeam. Außerdem habe ich gern auf Zeit gehärtete Backup Repositories, würde gern die Backups an zwei Standorten duplizieren, eine halbe handvoll von VMs sichern, den z.B. jährlichen Datenbestand komplett dem Zugriff einer EDV entziehen und so weiter und so fort - auch dies geht z.B. mit Veeam (gibt ja auch noch Alternativen). Wie ich dies alles mit Truenas umsetzen soll, entzieht sich jedoch im Moment meinem Verständnis.

Aus meiner persönlichen Brille kann nicht nachvollziehen, dass das nur einen Bruchteil des Komforts bieten soll, den veeam bietet. Einmal aufgesetzt verrichten die Replication tasks automatisiert ihren Dienst und wenn etwas nicht funktioniert, erhalte ich einen Alarm.

Siehe vorstehend und selbstverständlich verrichtet auch Veeam seinen Dienst automatisch und verschickt Alarme

Ich gebe dir Recht, dass das Aufsetzen eventuell nicht ganz so selbst erklärend ist, wenn man von den Standardeinstellungen abweichen möchte, aber ich bin der Meinung dass truenas insgesamt mit einer gewissen Lernkurve verbunden ist, da reiht sich das ganz gut ein.

Es geht doch nicht ums Aufsetzen der u.a. von Dir vorgeschlagenen Konstellation, sondern um die Praktikabilitaet und die "Benutzerfreundlichkeit" bei der Nutzung von Backups - vor allem dann, wenn man nicht täglich damit konfrontiert ist, aber gelegentlich schnell handeln muss. Da ist dann eine dedizierte Backupsoftware durchaus im Vorteil.

Ja zvols lassen sich ebenfalls darüber sichern.

Selbstredend, an sonst hätte ich ja keine replizierte Truenas

Wo hast du denn nach den Snapshots gesucht? Wenn du im Dataset Screen ein Dataset anwählst, werden dir rechts die Snapshots angezeigt bzw. du kannst dich von der Übersicht (Anzahl snapshots etc.) dahin begeben.

Jetzt vertust du dich aber, da ich mangels Datasets auch kein Snapshot eines solchen auswählen kann. Wie Du sicher erinnerst, verwende ich Zvols um diese als DAS-Volumen an einen Windowsdatenserver anzubinden und im Büronetzwerk freizugeben. Desgleichen müsste dann ja auch mit den Zvol-Snapshots erfolgen, aber da fehlt mir im Moment die Vorstellung, wie das funktionieren soll. Denn selbst wenn ich diese in der Verzeichnisstruktur des Systems finde würde (unter /mnt... sind diese jedenfalls erst einmal nicht), stellt sich mir immer noch die Frage, kann Windows diese dann auch als Volumen einbinden und die darin befindlichen Daten auch "erkennen"? Ich glaube eher nicht.

 

[Patrick M. Hausen]

Zvols sind keine Dateien sondern Artefakte innerhalb von ZFS und daher auch nirgends im Verzeichnisbaum. Wenn man das so macht, dann entfällt das schnelle Restore über .zfs/snapshots natürlich. Man kann nur das gesamte Zvol zu einem Zeitpunkt X lesen - natürlich auch per iSCSI zur Verfügung stellen - mit mehr Aufwand als bei Dateien auf einem Fileserver.

Daher kann ich deine Entscheidung für ein Windows-Backuptool nun nachvollziehen, allerdings nicht die Entscheidung, kein SMB zu verwenden. Weshalb tust du das? Also iSCSI - da braucht ja jeder PC sein eigenes. Ist aus meiner Sicht spontan erst mal "gaga" - nicht böse gemeint - daher würden mich die Gründe interessieren.

Dann noch:

Gern kann man dies auch als "Backup" bezeichnen, ich würde die Sache eher als Spiegelung sehen.

Wenn man ein drittes System nimmt, das die Snapshots über Jahre vorhält und bei dem nicht geplant ist, es jemals "online" zu nehmen, wird aus der Spiegelung ein Backup. Das ist ja eine eher organisatorische Frage als eine technische. Und zur reinen Replikation gibt es nun mal nichts performanteres und auch nichts sichereres als ZFS send/receive. Weil alle Daten mit Checksummen abgesichert sind.

Wohin sichert denn dein Veeam? Ist da dann ein ZFS drunter? Wenn nein, was tust du gegen Bitrot?

 

[chuck32]

Jetzt vertust du dich aber, da ich mangels Datasets auch kein Snapshot eines solchen auswählen kann.

Mir war nicht klar, dass du dich jetzt ausschließlich auf zvols beziehst bzw. nur iSCSI verwendest. Hatte ich nicht in der Lesart verstanden. Zumal das nicht OPs Anforderung ist und ich einfach noch einmal klar stellen wollte, dass für OP eine Replikation durchaus eine gute Lösung darstellen kann.

Daher kann ich deine Entscheidung für ein Windows-Backuptool nun nachvollziehen

Unter den Gesichtspunkten liegt der Punkt klar bei veeam, da bin ich dabei.

Von einem "Backup" erwarte ich weitere Fähigkeiten, vor allem auch die Möglichkeit, einzelne, versionierte Dateien und Verzeichnisse schnell wiederherstellen zu können, denn man glaubt es kaum, meine Mitarbeiter "zerschießen" dann doch das eine oder andere.

Bei SMB und snapshots bräuchte es da nichtmal ein backup.

Und dasselbe geht auch für Verzeichnisse. In Windows habe ich Wiederherstellen deaktiviert auf den Rechnern, damit nicht jemand aus Versehen das ganze Verzeichnis wiederherstellt. Und so kann sich jeder alte Versionen öffnen und seine Dateien wiederherstellen.

. Ich werde mal die Replikation und insbesondere den Zugriff auf die Snapshots testen. Muss mich halt noch einlesen. Mein Thema ist, dass ich im Falle eines Ausfalls nicht etliche Stunden oder Tage mit der Wiederherstellung verbringen kann.

Das kommt ehrlich gesagt ganz darauf an wie du im Fall der Fälle mit dem Ausfall umgehst. Grundsätzlich kommst du binnen Minuten an deine Daten, die sind ja da und verfügbar. Du kannst direkt von der Remotemaschine drauf zugreifen wie von deiner Hauptmaschine auch (ich unterstelle hier dass sich dein Remote-Linux Server da nicht groß von truenas unterscheidet, wenn der ZFS kann wüsste ich jetzt nicht wieso du nicht auch dort deine Datasets als Share bereitstellen könntest).

 

[bic]

.... allerdings nicht die Entscheidung, kein SMB zu verwenden. Weshalb tust du das? Also iSCSI - da braucht ja jeder PC sein eigenes. Ist aus meiner Sicht spontan erst mal "gaga" - nicht böse gemeint - daher würden mich die Gründe interessieren.

Die Entscheidung dafür liegt lange zurück und resultiert aus der Notwendigkeit, also des Aufwands der doppelten Rechteverwaltung bei der Verwendung eines Windows AD im Zusammenhang mit einem NAS und der hieraus resultierenden Fehlerträchtigkeit. Daher hatte ich bereits bei meinem überhaupt ersten NAS (ein Maxdata-Server unter Open-e) und dem damaligen AD von Windows 2000 geschaut, wie man das unter einen Hut bringen kann. Hierbei habe ich dann zu meiner Freude festgestellt, dass ich, wenn ich den Maxdata-Server nicht als NAS, sondern per iSCSI als SAN einrichte (Open-e konnte das damals schon), die dort eingerichteten Volumen als Direct Attached Storage auf dem Windowsserver einbinden, genau wie solche behandeln und auch für das Netzwerk freigeben konnte (iSCSI konnte damals nur die Serverversion). Hier mal mein derzeitiger ADC zu Hause, die Datenträger 1 bis 3 sind die iSCSI-Volumen:

Jedenfalls war damit das Problem der doppelten Rechteverwaltung vom Tisch, ist es dies bis heute und alles "bewegt" sich im AD.

Es ist daher nicht notwendig jedem PC eine iSCSI-Verbindung zum SAN zu spendieren (dies würde zwar gehen, aber zu Datenverlusten führen), es reicht ein einziger, im AD intergierter PC (es muss ja nicht der ADC sein), in welchem man die iSCSI-Volumen für das Netzwerk freigibt und die Rechte der Volumen verwaltet - einfacher geht es kaum. Hier mal die ziemlich simplen Freigaben (es greifen ja nur zwei vertrauenswürdige User - meine Frau und ich- darauf zu) der drei oben gezeigten Volumen:

Wohin sichert denn dein Veeam? Ist da dann ein ZFS drunter? Wenn nein, was tust du gegen Bitrot?

Nein, da ist kein ZFS drunter, wäre aber möglich. Ich sichere quasi über Kreuz auf zwei RDX-Appliancen, welche lange Zeit unter Linux liefen und die Daten in ein gehärtetes xfs schrieben. Da aber nach irgendeinem Linux-Versionsupdate der Veeam-Agent Probleme bereitete, habe ich auf W19 umgestellt und sichere auf ReFS-formatierte Datenträger. Und was den Bitrot anbelangt - nun, ein bißchen Schwund ist überall Nö, die RDX-Datenträger werden regelmäßig, naja eher gelegentlich getauscht.

 

[bic]

Bei SMB und snapshots bräuchte es da nichtmal ein backup.

Und dasselbe geht auch für Verzeichnisse. In Windows habe ich Wiederherstellen deaktiviert auf den Rechnern, damit nicht jemand aus Versehen das ganze Verzeichnis wiederherstellt. Und so kann sich jeder alte Versionen öffnen und seine Dateien wiederherstellen.

Nun ja, ich benötige aber schon aus rechtlichen Gründen ein dediziertes Backup, Schattenkopien sind dafür nicht so recht geeignet. Und dass sich jeder Mitarbeiter alte Dateiversionen öffnen und diese wiederherstellen kann, kommt für mich aus hier nicht näher zu erläuternden Gründen ohnehin nicht in Frage. Sorry ... ich sage ja immer "jedem Tierchen sein Pläsierchen", aber schön, dass Du mich zu überzeugen versuchst

 

[chuck32]

Nun ja, ich benötige aber schon aus rechtlichen Gründen ein dediziertes Backup, Schattenkopien sind dafür nicht so recht geeignet.

OP möchte aber Familienfotos sichern. Beziehe meine Antworten nicht zu sehr auf deinen Geschäfts Use case, da fehlt mich zugegebenermaßen das Know-how um da sinnvoll etwas beitragen zu können.

Mir geht es wie gesagt darum, einfach ein paar Infos/Erfahrungen auszutauschen zu geben die deiner Aussage

Hmmm, eine Replikation auf eine zweite Truenas betreibe ich auch, nur ist dies zumindest nach meiner unmaßgeblichen Meinung kein wirkliches Backup.

etwas entgegen stehen, damit eben klar gestellt ist, dass das für OP eine sinnvolle Lösung sein kann. Zumindest meiner Meinung nach.