(QNAP) Backup NAS

[Gen8 Runner]

Moin,
zu meinem Homeserver (siehe Signatur), möchte ich nun eine etwas elegantere Backup-Lösung haben.

Stand derzeit:
- Festplatte anklemmen -> Dateien kopieren -> Festplatten abklemmen und woanders lagern

Plan:
NAS (anschaffen), wohin per VPN oder Standard Netzwerkkabel meine Daten hingeschoben werden. Nun habe ich hier schon ein 2-Bay QNAP NAS System herumfliegen (Schnäppchen gemacht). Wenn ich hier beide Festplatten à 12TB einbaue, stehen allerdings nur 24TB Kapazität zur Verfügung, es müssten aber insgesamt an die 48TB werden. Kann man bei QNAP erst einen Teil des Backups auf die Platten schieben und diese anschließend sicher unmounten und bei Bedarf (Backup einspielen) wieder mounten? Wie schimpft sich das bei QNAP? JBOD, sprich Platten können EINZELN gemountet und ausgelesen werden oder wie genau? Den Rest dann auf die dauerhaft im QNAP verbauten Festplatten schieben und im Backupfall eben mit den Festplatten jonglieren?
Oder was sagt ihr zu der Überlegung? 2-Bay NAS verkaufen und 4 Bay NAS anschaffen? RAID nicht wirklich notwendig, da wie gesagt "nur" Backup.

Andersherum: Wenn die QNAP mit vier Platten dauerhaft am Netz hängt und der Strom sich seine Opfer sucht, sind auch direkt alle vier Platten im Mors und auch die Backups somit zerschossen, was widerrum für das 2-Bay NAS sprechen würde.

Schmeißt mal eure Idee in den Raum, wie es am elegantesten wäre.
Cloud-Backup ist keine Option, da einfach zu großer Datenbestand für die Leitung & auch eine Kostenfrage. Festplatten an- und abklemmen finde ich einfach nur ätzend und lasse daher das Backup auch öfter ziemlich schleifen.

Danke!

 

[whs2]

Ich würde einen alten PC mit Unraid als Datenschlampe empfehlen. Qnap kann das m.E. nach nicht. Asustore hat mir der Archiv Funktion aber diese Möglichkeit.

 

[Ceiber3]

Oder was sagt ihr zu der Überlegung? 2-Bay NAS verkaufen und 4 Bay NAS anschaffen? RAID nicht wirklich notwendig, da wie gesagt "nur" Backup.

Würde ich so machen. Geht also rein um Backup ? Du meinst jetzt jede Platte als Single Disk mounten ? Das sollte gehen. Warum kein Raid ?

 

[Mo3Jo3]

Du meinst jetzt jede Platte als Single Disk mounten ? Das sollte gehen. Warum kein Raid ?

Wieso Single Disk? Hier bietet sich doch ein Jbod RAID an.
Wenn man keine Redundanz braucht, wieso dann Speicher vergeuden?

 

[Ceiber3]

Wieso Single Disk? Hier bietet sich doch ein Jbod RAID an.

RAID nicht wirklich notwendig, da wie gesagt "nur" Backup.

 

[Mo3Jo3]

@Ceiber3
Also ich bin mir ziemlich sicher dass Gen8 Runner ein RAID mit Redundanz(darauf bezieht sich das nicht nötig) meinte. Was du schreibst ergibt doch keinen Sinn. Wenn er beispielsweise 15TB an Video Daten rum liegen hat, müsste er die Daten ja splitten und manuell auf zwei separaten Platten speichern.
Ich glaube nicht, dass sowas gewollt ist.

 

[Gen8 Runner]

Danke schonmal für eure Einwürfe und Ideen. Ein alter Rechner mit Unraid wäre eventuell auch noch ne Option.
Prinzipiell RAID oder nicht, wäre mir egal. Was ich nur absolut nicht möchte ist, dass bspw. eine von vier Platten ausfällt und dann auch die Daten der drei anderen Platten weg sind, da die Paritätsdaten (?) auf allen Platten verteilt waren.

Sonst, wenn eine einzelne Festplatte während des Recoverings ausfällt und diese Daten weg sind, wäre das egal.

 

[Ceiber3]

Was ich nur absolut nicht möchte ist, dass bspw. eine von vier Platten ausfällt und dann auch die Daten der drei anderen Platten weg sind, da die Paritätsdaten (?) auf allen Platten verteilt waren.

So was ist mir im Leben noch nie passiert. Die Paritätsdaten sind bei einen Raid eh immer auf allen Festplatten verteilt. Sprich, fällt bei einen Raid 5 eine Festplatte aus, läuft das Raid ganz normal weiter. Fällt beim Rebuild eine weitere Festplatte aus, sind alle Daten hin. Bei nen Raid 6 können halt zwei Festplatten ausfallen und es läuft normal weiter usw...

 

[Gen8 Runner]

So was ist mir im Leben noch nie passiert. Die Paritätsdaten sind bei einen Raid eh immer auf allen Festplatten verteilt. Sprich, fällt bei einen Raid 5 eine Festplatte aus, läuft das Raid ganz normal weiter. Fällt beim Rebuild eine weitere Festplatte aus, sind alle Daten hin. Bei nen Raid 6 können halt zwei Festplatten ausfallen und es läuft normal weiter usw...

Genau, richtig.

Bspw.: RaidZ1 (für ZFS). Eine Festplatte fällt aus -> RAID funktioniert weiterhin -> eine weitere fällt aus -> Alles hinüber.

GIbt es kein Raid-Level oder andere Art von Plattenverbund, wo auch nur die wirklich defekte Festplatte betroffen ist?
Bspw:
4 Platten
Nr. 1 fällt aus -> 2,3,4 weiterhin vorhanden
Nr. 2 fällt auch aus -> 3,4 vorhanden
Nr. 3 fällt aus -> 4 noch weiterhin vorhanden

Klar wird es immer eine überlappende Datei geben, die dann auch beschädigt wäre, aber das wäre nicht das große Malheur.


Wie schimpft sich das bei QNAP / Synology? JBOD?

 

[Mo3Jo3]

Jbod ist eigentlich kein RAID, sondern nur ein Array ohne Redundanz aus mehreren Festplatten, so wie du es oben beschrieben hast.
Ich selber habe das noch nicht benutzt, deshalb weis ich nicht wieviel Kontrolle man darüber hat, wo die Daten genau liegen. Wenn Dateifragmente natürlich immer auf alle Festplatten verteilt werden, ist das etwas suboptimal....

 

[tolga9009]

Alter PC, Ubuntu / CentOS, SnapRAID, mergerFS. Wenn du keine Parity konfigurierst, sind beim Ausfall nur die Daten der betroffenen Festplatte weg. Nach außen hin wird es über mergerFS als einziger, großer Pool repräsentiert (JBOD).

 

[gea]

Also ich weiß nicht.

48 TB mit Daten zu füllen dauert übers Netz mal mindestens eine Woche. Ohne Raid fällt irgendwann eine Festplatte aus (die Frage ist nicht ob sondern nur wann). Bei Raid-0 ist alles weg. Bei Snapraid etc zwar nur die Daten einer Platte seit dem letzten sync aber das möchte ich ehrlich gesagt auch nicht von meinem Backup haben.

Um 48 TB wirklich sicher zu haben
- 6 Platten a 12 TB oder 7 Platten a 10 TB nehmen und damit ein ZFS Z2 bauen und regelmäßig Snaps erstellen.

Das verkraftet zwei Plattenausfälle ohne Datenverlust, prüft/repariert alle Daten in Echtzeit beim Lesen (oder scrub) und das Dateisystem kann nicht bei einem einfachen Crash beim Schreiben sterben. Dazu Ransomware sichere readonly Versionierung via Snaps.

Falls man darauf per Internet sichern möchte ist VPN eine Option, die andere das Amazon S3 Protokoll z.B. via minIO (Opensource S3 Server, auch auf ZFS). Damit hat man Cloud Zugriff der gerne mal 10X schneller ist als VPN via S3 Sync Tools, z.B. https://proprivacy.com/cloud/comparison/amazon-s3-user-interface-tools

 

[tolga9009]

Ich denke der entscheidende Punkt ist:

Stand derzeit:
- Festplatte anklemmen -> Dateien kopieren -> Festplatten abklemmen und woanders lagern

Das neue System soll sein jetziges Offline-Backup ersetzen, da es bei 48TB unhandlich wird (nachvollziehbar). Da finde ich Webzugriff / Cloud / NAS unpassend. Ein Offline Backup hat schon seine Vorteile: sicher vor Stromproblemen und sicher vor Angriffen. Außer vielleicht Brand, Diebstahl und Lagerungsschäden kann nicht viel passieren. Wenn jemand (Remote-)Zugriff auf das System mit den entsprechenden Berechtigungen erlangt, dann nützt auch der Read-Only Snapshot und das ungemountete Volume nichts.

48 TB mit Daten zu füllen dauert übers Netz mal mindestens eine Woche.

Allerdings nur bei der ersten Übertragung. Die folgenden Backups können je nach verwendeten Software inkrementell laufen.

Bei Snapraid etc zwar nur die Daten einer Platte seit dem letzten sync aber das möchte ich ehrlich gesagt auch nicht von meinem Backup haben.

Man kann selbst bestimmen, wann der Sync stattfindet. Das würde man in diesem Fall direkt im Anschluss an das Backup machen, das bietet sich hier sehr gut an. Stelle mir das Backup-System so vor, dass es nur für ein Backup läuft und anschließend wieder runtergefahren wird. Insgesamt also ein "Offline-Backup", was lediglich den Komfort verbessert bzw. das Rumhantieren mit den externen Festplatten vermeidet.

OP schaltet also Backup-System ein, lässt sein Backup-Skript laufen und fährt es wieder runter. MergerFS kümmert sich um die Sortierung der Daten auf die jeweiligen HDDs und SnapRAID kümmert sich um Checksummen (und Partität, falls gewünscht).

Horrorszenario "Blitzeinschlag während des Backup-Vorgangs": 4 von 6 Festplatten tot. Dank SnapRAID / mergerFS sind die Daten der beiden intakten Festplatten weiterhin lesbar und auf Integrität überprüfbar.