Ideale Server-Konfig für externen Speicher

[S3v|\|]

Hallo zusammen

meine aktuelle Proxmox Backup Server (PBS) Konfig ist wie folgt:
Auf meinem Proxmox Virtual Environment (PVE) läuft eine PBS-VM. Diese sichert täglich über SMB auf eine QNAP-NAS mit Festplatten.
Diese Konfig läuft so weit recht OK - nur bei Verify, Prune und Garbage Collect stößt sie an die Grenzen.
Die zur Verfügung gestellte (virtuelle) Hardeware wird nie voll ausgenutzt. (16 GB RAM, 4 Kerne)
Dass diese Konfig nicht ideal ist, ist mir inzwischen auch bewusst geworden.
Daher möchte ich mein PBS - Setup komplett neu aufbauen.
Ich weiß auch, dass als PBS-Backup-Datastore ein interner SSD Speicher ideal wäre. Aber das ist bei mir auf Grund der Datenmenge (zig TB) und des zur Verfügung stehenden Budgets nicht möglich.

Mein Grundgedanke ist folgender:
- ein kleiner Hardware Server mit zwei SSDs im ZFS Verbund für das Betriebssystem (vermutlich eine M.2 NVMe und eine SATA)
Ansonsten ungefähr gleiche Hardware wie in der VM
( https://pbs.proxmox.com/docs/installation.html#recommended-server-system-requirements )
- ein TrueNas (wollte ich mir sowieso basteln - auch für andere Aufgaben) auch mit zwei SSDs im ZFS Verbund für das Betriebssystem (vermutlich eine M.2 NVMe und eine SATA)
- mehrere Festplatten im ZFS Verbund für die Daten

Meine Fragen:
- Ist an der Grundidee etwas gravierend falsch?
- Hat jemand direkt Erfahrung mit den Geschwindigkeitsunterschieden zwischen VM und Hardware? Bringt das bei Verify, Prune und Garbage Collect wirklich etwas?
- wie sollte die TrueNas am besten angesprochen werden? Wieder per SMB oder evtl. über iSCSI oder gibt es eine ganz andere Technik, die ich gar nicht kenne (z.B. das True-NAS-ZFS direkt im PBS einzubinden)?
- Bringt es etwas bei dem Daten-ZFS ein special device oder ein caching device einzubinden? (was ist da eigentlich der Unterschied?)
- Kann ich meine bisherigen Sicherungen dann mit dem neuen PBS weiterverwenden? muss ich evtuell einen Schlüssel aus dem alten PBS exportieren oder liegen die Schlüssel auf den PVE-Servern?
- Ist es prinzipiell möglich das Backup auf eine kleine interne SSD zu speichern und dann nachträglich auf die TrueNAS wegkopieren? (Ich vermute aufgrund der Wiederverwendung der Blöcke eher nicht - da ja sonst der Datastore aus zwei Speichern bestehen müsste.)

Grüße

 

[Falk R.]

Alles was du über Netzwerk an den PBS anschließt ist schon mal schlecht. Auch wenn du HDDs nutzt, am besten direkt anbinden.
Wenn du einen gut laufenden PBS mit HDDs möchtest, dann einen ZFS Pool mit 2 vernünftig schnellen, kleinen NVMe als Special Device.
Damit klappt das deutlich besser, aber Verify hängt immer an der HDD Performance.
Nutzt du einen gebrauchten Server mit vernünftigen Raid Controller incl. BatterieCache, dann den Cache nutzen und XFS auf dem PBS. Damit bekommst du auch akzeptable Performance aus den HDDs.

Alles per NFS oder SMB ist per Design immer langsam und macht nicht glücklich.

 

[TErxleben]

Bei deinem Dilemma hast du folgende Flaschenhälse:

• Netzwerkanbindung
• Anbindung des Speichermediums (Thunderbold schafft theoretisch 40GB/s
• HDD statt SSD
• Letzteres kannst du mit einem Cachemechanismus wie @Falk R. erwähnte, ein wenig entschärfen.

Aufgrund der Deduplizierung eines PBS, hast immer mit kleinen Datenblöcken zu tun. Da stinken HDDs ggü. SSDs gewaltig ab. Die kolportierten gewaltigen Durchstzleistungen beziehen sich immer auf riesige Dateien am Stück, die es im real Life so gut wie nie gibt.

Grundsätzlich enthalten deine Gedanken keine grobe Schnitzer.
Ich installiere z.B. eine PBS-VM gerne komplett auf fetten externen Platten. 16TB+. Damit sind sie extrem portabel und ab einem gewissen Füllstand lahmarschig (12h für eine GC). Das sind sie aber auch bei interner Anbindung.

Letzlich hängt es vom verfügbaren Budget und Anforderungen ab.

 

[S3v|\|]

Mein Hauptproblem ist wirklich die große Datenmenge:
Aktuell hab ich zwei PVE-Cluster. Auf jedem läuft ein Windows DFS File Server mit ca 10 TB Daten die sich gegenseitig abgleichen + weitere Systeme.
(Diese Größe ist für mich auch ein Problem, da ich somit keine Wiederherstellungstests machen kann)
Beide Cluster sichern auf einen PBS. Für jeden Cluster hab ich einen eigenen Backup-Datastore auf zwei QNAP NAS-Systemen.
In der Summe sind es aktuell über 100TB auf beiden NAS-Systemen.

Das bekomme ich nicht als SSD in einen PBS-Server (weder platzmäßig noch finanziell)

Backup und prune laufen halbweg gut durch.
Nur mit garbage collection hab ich echt ein Problem.

Ich weiß, dass ein externer Speicher nicht optimal ist - aber ich versuche aus den Gegebenheiten die optimale Lösung zu finden.
Und von den QNAP will ich weg. Da hab ich aus mehreren Gründen schlechte Erfahrung gemacht. Diese hätte ich dann durch zwei TrueNas oder zwei OMV ersetzt.

Und wenn ich dann schon am Geldausgeben bin, dann hätte ich meinem PBS gleich noch bare metal spendiert in der Hoffnung, dass dieser dann performanter als eine VM ist.

 

[TErxleben]

Und wenn ich dann schon am Geldausgeben bin, dann hätte ich meinem PBS gleich noch bare metal spendiert in der Hoffnung, dass dieser dann performanter als eine VM ist.

Mit Baremetal statt VM machst aus HDD-Ackergäulen nie SSD-Rennpferde.
Wie kommen 100TB zustande, wenn du zweimal 10TB hast?
Wie lange läuft bei dir eine GC?
Kannst du Bewegungsdaten nicht klug von Archivdaten trennen?

 

[Falk R.]

Auch die zwei FS werden ja wieder Dedupliziert. Da hast du hoffentlich kein MS Dedup aktiviert, was so riesige Backupmengen erklären könnte.

 

[TErxleben]

Auch die zwei FS werden ja wieder Dedupliziert. Da hast du hoffentlich kein MS Dedup aktiviert, was so riesige Backupmengen erklären könnte.

Irgendwie eine vertrackte Situation. Logischerweise ist die Deduplizierung bereits deduplizierter Daten zumindest ein Karusselbremser und immer ein Speicherfresser.
Ich gehöre nun nicht zu den "ZFS-Fanbois" aber bzgl. ZFS läuft Kommunikation im Internet völlig falsch. Da wird immer von gigantischem RAM-Verbrauch geschwafelt, was völlig am Thema vorbei ist und die weite Verbreitung behindert (neben anderen Nickligkeiten). Die Vorteile werden nie erwähnt.
Es gibt natürlich viele Leute, die sich wundern, warum ein zip nicht erheblich kleiner wird als die darin enthaltenen jpegs.
Fakt ist, dass ich keine Distribution kenne, die ZFS standardmäßig einsetzt. Das sagt jemand, der gerne ReiserFS eingesetzt hat.
Darum setze ich als Basis immer noch auf z.B. ext4 mit ausreichend Speicherplatz und erreiche bei der Sicherung Deduplizierungsraten >10.

ZFS als Ersatz klassischer RAID-Systemen ist ohne Frage eine gute Idee. ZFS im Brot und Butter Umfeld unnötig kompliziert.

Nur ein Schwank aus meinem Leben...

 

[Falk R.]

Irgendwie eine vertrackte Situation. Logischerweise ist die Deduplizierung bereits deduplizierter Daten zumindest ein Karusselbremser und immer ein Speicherfresser.
Ich gehöre nun nicht zu den "ZFS-Fanbois" aber bzgl. ZFS läuft Kommunikation im Internet völlig falsch. Da wird immer von gigantischem RAM-Verbrauch geschwafelt, was völlig am Thema vorbei ist und die weite Verbreitung behindert (neben anderen Nickligkeiten). Die Vorteile werden nie erwähnt.
Es gibt natürlich viele Leute, die sich wundern, warum ein zip nicht erheblich kleiner wird als die darin enthaltenen jpegs.
Fakt ist, dass ich keine Distribution kenne, die ZFS standardmäßig einsetzt. Das sagt jemand, der gerne ReiserFS eingesetzt hat.
Darum setze ich als Basis immer noch auf z.B. ext4 mit ausreichend Speicherplatz und erreiche bei der Sicherung Deduplizierungsraten >10.

ZFS als Ersatz klassischer RAID-Systemen ist ohne Frage eine gute Idee. ZFS im Brot und Butter Umfeld unnötig kompliziert.

Nur ein Schwank aus meinem Leben...

Was hat das Thema Backup denn mit ZFS zu tun?
ZFS Compression ist cool, aber der PBS macht auch auf XFS und ext4 die gleiche Deduplizierung.

Ich befürchte der TE hat Deduplizierte FS und da jeder selbst dedupliziert, sind die Chunks vermutlich auch noch verschieden.
Damit hat man Produktiv ein wenig gespart aber muss ein vielfaches fürs Backup investieren.

 

[Johannes S]

Zum Thema HDDs und Netzwerkspeicher wurde ja schon einiges geschrieben, wenn du die Daten auf neue TrueNAS oder OMV-Instanzen umziehst, würde ich neben Falks Vorschlag mit Batterie-Cache trotzdem auch noch mal ZFS testen, dann aber nur mit einen SSD-Mirror (wegen wegen Ausfallsicherheit) als special device: https://pbs.proxmox.com/docs/sysadmin.html#zfs-special-device

Damit werden dann Metadaten (und wenn man will auch kleine Dateien, aber da die Limits richtig festzulegen ist eine Wissenschaft für sich...) auf den SSDs gespeichert (Kapazität sollte bei 0,02-2 % der HDD-Kapazität liegen). Ergebnis: Tasks, die (wie garbage-collect) vor allen so Sachen wie Dateigrößen, Änderungs-, Erstellungs- und Zugriffsdatum betrachten müssen gehen deutlich schneller, da die dann von den SSDs statt der lahmen HDDs gelesen werden können. Es könnte also einen Versuch wert sein, dass mit den Batterie-Cache zu vergleichen. Wichtig dabei: Man braucht dann auf jeden Fall im special device soviel Redundanz wie bei den HDDs, da bei Verlust des special device auch die auf den HDD gespeicherten Daten (mangels Metadaten) nicht mehr erreichbar sind! Und es landen nur neue Daten im special device, envtl. in den HDDs bereits vorhandene muss man dann mit zfs send/recv neu schreiben. Heiß also mindestens zwei SSDs, je nach Szenario auch mehr (wenn z.B. man sein RAID so aufgebaut hat dass zwei HDDs ausfallen dürfen, dann braucht es mindestens drei SSDs etc).

Zu beachten dabei: ZFS und HW-Raid mögen sich nicht so wirklich (sofern man nicht auf bestimmte Sachen achtet, da weiß @Falk R. mehr zu), daher sollte man in meinen Augen folgende Szenarien benchmarken:

• HW Raid mit ext4 oder xfs (bei TrueNAS nicht möglich!) ohne Batterie-Cache
• HW Raid mit ext4 oder xfs (bei TrueNAS nicht möglich!) und aktivierten Batterie-Cache
• ZFS ohne HW Raid (und somit ohne Batterie Cache) mit und ohne special device
• (falls möglich, ich meine es geht, wenn man das virtuelle Device des HW-Raid in einen 1-disk-vpool überführt oder @Falk R. ? ): ZFS mit HW Raid (falls möglich, bin mir nicht sicher!) mit und ohne batterie cache und mit und ohne special device Diese Option sollte man lassen, wenn einen die eigenen Daten lieb sind, siehe Hinweis von Falk in seiner Antwort

Ansonsten würde ich auch mal erwägen, ob du den PBS nicht direkt auf dem NAS laufen lassen kannst. OpenMediaVault und TrueNAS erlauben ja beide auch VMs zu betreiben, damit hättest du dann das Netzwerk als Flaschenhals schon mal raus. Die Virtualisierung plus die Einbindung des Datastores als NFS/cifs-Freigabe mit dazugehörigen Overhead wird natürlich trotzdem ein wenig kosten, aber generell scheint das für viele User besser zu funktionieren als vom PBS aus über das Netzwerk auf den Datastore zuzugreifen, hier ein Beispiel (allerdings von einen Heimanwender): https://forum.proxmox.com/threads/warum-ist-der-pbs-so-picky-bei-nfs-storage-mounts.160610/
Diese Netzwerkfreigabe sollte dann aber natürlich nur von localhost zugreifbar sein, damit kein Angreifer den Datastore manipulieren kann. Ich bin mir gerade unsicher, ob und wie virtiofs-Freigaben (damit entfällt die Notwendigkeit für nfs oder cifs) bei TrueNAS oder OMV möglich sind. Die Performance soll da aber schlechter sein (siehe: https://forum.proxmox.com/threads/i-want-to-like-virtiofs-but.164833/ ), aber solange sie gut genug/besser als der Weg übers Netzwerk ist, reicht das ja. Oder man erstellt den Datastore analog zu VMs unter ProxmoxVE gleich als virtuelles Laufwerk, damit hat man aber halt den Overhead eines weiteren Dateisystems. Also wieder: Verschiedene Möglichkeiten benchmarken.

Nicht unerwähnt sollte werden, dass sowohl OMV als auch TrueNAS mittlerweile auch erlauben den PBS als Container zu betreiben (siehe: https://forum.proxmox.com/threads/pbs-on-truenas-have-your-cake-and-eat-it-too.162860/ ). Damit sollte nochmal mehr Performance möglich sein, da der ganze Virtualisierungs-Overhead entfällt. Es ist aber ein nicht von den PBS-Entwicklern vorgesehenes oder getestetes Szenario, daher wäre ich damit bei einen beruflichen Setup eher vorsichtig damit. Ein weiteres Problem ist, dass die TrueNAS-Entwickler gerne mal ihren Virtualisierungs- oder Containerstack umbauen (in den letzten Jahren gab es da bestimmt vier mal mehr oder weniger große Änderungen), was nicht unbedingt jeden gefallen muss. Sie haben aber bislang auch immer an Migrationswege gedacht, trotzdem bin ich für sowas ein bissel zu konserativ gestrickt
Dafür hat TrueNAS ZFS nativ an Bord (dafür aber keine Unterstützung für andere Dateisysteme, envtl. blöd, wenn du gerne HW-Raid mit xfs oder ext4 nutzen wollen würdest) und ist generell in der NAS-Funktionalität eher für den Enterprise-Einsatz entwickelt inklusive der Möglichkeit genau darauf abgestimmte Hardware und Support vom Hersteller zu kaufen. OpenMediaVault ist dagegen ein Community-Projekt, dass von Spenden lebt (was KEIN Diss ist, aber solche Sachen können ja wichtige Kriterien bei Entscheidungen sein).

Durch die ZFS-Integration ist es auch sehr einfach zwischen verschiedenen TrueNAS-Instanzen hin- und her zu synchronisieren. Und anders als @TErxleben bin ich bekennender ZFS-Fanboy, darum möchte ich doch etwas klarstellen:

Fakt ist, dass ich keine Distribution kenne, die ZFS standardmäßig einsetzt. Das sagt jemand, der gerne ReiserFS eingesetzt hat.

Das hat allerdings eher rechtliche Gründe (die zwar hoch umstritten sind, ob das überhaupt einklagbar wäre, aber die Distributionen sind da zum Großteil halt lieber safe than sorry), bei FreeBSD und Abkömmlingen (OPNSense, XigmaNAS ...) sind die nicht gegeben und da kann man ZFS dann auch direkt im Installer auswählen. Und auch bei Linux gibt es Distributionen, die standardmäßig oder zumindestens als Option beim Installieren das anbieten, oder sind TrueNAS Scale (was sogar nur zfs unterstützt , unraid, ProxmoxVE, ProxmoxBackupServer oder ProxmoxMailGate keine Distributionen, weil da die bunte GUI fehlt? Und Ubuntus Kernel unterstützt es zumindestens, man muss aber halt die Utils nachinstallieren. Zumindestens bislang kann man es auch im Installer auswählen, auch wenn es bei Canonical Überlegungen gibt das rauszuwerfen, da es leider bei denen keine große Priorität hat, siehe https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/1968150

Sprich: Ich sehe keinen Grund auf die Vorteile von zfs (https://forum.proxmox.com/threads/f...y-a-few-disks-should-i-use-zfs-at-all.160037/ ) zu verzichten, außer man hat einen wirklich guten Grund dafür. Batterie-Cache in HW-Raid ist einer, der FUD von jemanden, der es für praktikabel hält den ProxmoxBackupServer samt Datastore auf USB-Festplatten zu installieren eher nicht.

Edit: Blödsinn zu ZFS- und Batterie-Cache ausgekreuzt.

 

[Falk R.]

• (falls möglich, ich meine es geht, wenn man das virtuelle Device des HW-Raid in einen 1-disk-vpool überführt oder @Falk R. ? ): ZFS mit HW Raid (falls möglich, bin mir nicht sicher!) mit und ohne batterie cache und mit und ohne special device

Beim PBS braucht man kein ZFS mit HW Raid, macht nur Sinn wenn ich Replikation im PVE nutzen möchte.
Dann ein Single vDev vom HW Raid Volume und niemals den Pool erweitern, Mirror oder Special Device hinzufügen.

 

[Johannes S]

Dann ein Single vDev vom HW Raid Volume und niemals den Pool erweitern, Mirror oder Special Device hinzufügen.

Das war der eigentliche Grund meiner Frage, ich habe mich gefragt, ob man nicht den HDD-HW-RAID-Pool dann mit einen special device verknüpfen könnte, um damit das Setup noch weiter zu beschleunigen. Dann also besser nicht, danke der Korrektur

 

[Johannes S]

Was ich noch vergessen habe: OpenMediaVault basiert ja auch auf Debian und anders als bei TrueNAS kann man da auch relativ einfach zusätzliche Pakete installieren. Theoretisch könnte man da also den ProxmoxBackupServer samt Proxmox-Kernel auch manuell auf das Bestandsystem packen:
https://pbs.proxmox.com/docs/installation.html#install-proxmox-backup-server-on-debian
Das hätte den Charme, dass man sich damit jeglichen overhead durch Container/Netzwerk etc komplett spart. Außerhalb eines Homelabs würde ich das aber trotzdem nicht betreiben wollen, weil das halt ein Szenario ist, was mit Sicherheit keiner der Entwickler (egal ob bei PBS oder OMV) testet, was möglicherweise Support bei Problemen schwerer machen könnte.

 

[S3v|\|]

Zu den 100 TB möchte ich folgendes ergänzen:
die beiden DFS-Server sichern sich auf unterschiedliche Datastores - da sollte meiner Meinung keine Dedublizierung möglich sein, da jeder Datastore für sich vollständig sein sollte. Außerdem laufen ja nicht nur die beiden Server - das sind nur die größten. Und ja - man könnte die Sicherungen etwas mehr ausmisten - aber lieber mehr haben und nicht brauchen als andersrum. Vor allem, da ich mehrere Sicherungen hab, bei denen Verify fehlgeschlagen hat. (Aber dazu mach ich gleich noch einen anderen Thread auf )

Eine Bastellösung à la PBS in Container auf einer NAS möchte ich auch nicht. Es sollte schon hinterher verlässlich funktionieren. Außerdem hätte ich dann nur Vorteile wenn ich auf den Speicher einer NAS zugreifen möchte. Sobald ich aber eine weitere NAS als weitern Datastore einbinden möchte hab ich wieder keinen Vorteil.

 

[Falk R.]

Zu den 100 TB möchte ich folgendes ergänzen:
die beiden DFS-Server sichern sich auf unterschiedliche Datastores - da sollte meiner Meinung keine Dedublizierung möglich sein, da jeder Datastore für sich vollständig sein sollte. Außerdem laufen ja nicht nur die beiden Server - das sind nur die größten. Und ja - man könnte die Sicherungen etwas mehr ausmisten - aber lieber mehr haben und nicht brauchen als andersrum. Vor allem, da ich mehrere Sicherungen hab, bei denen Verify fehlgeschlagen hat. (Aber dazu mach ich gleich noch einen anderen Thread auf )

Eine Bastellösung à la PBS in Container auf einer NAS möchte ich auch nicht. Es sollte schon hinterher verlässlich funktionieren. Außerdem hätte ich dann nur Vorteile wenn ich auf den Speicher einer NAS zugreifen möchte. Sobald ich aber eine weitere NAS als weitern Datastore einbinden möchte hab ich wieder keinen Vorteil.

Die 2 DFS Server sollten natürlich getrennt liegen, aber im Backup Datastore würden die dedupliziert werden, solange da keine Microsoft Deduplizierung aktiv ist.
Das mit dem Verify wunder mich nicht wirklich.
Veeam empfiehlt auch seit Jahren, keine NAS zu nutzen, denn laut deren Support sind 90% aller defekten Backups auf NAS Systemen.
Da du beim PBS auch noch den Performancenachteil des NFS hast, solltest du das Thema NAS (egal was für eins) für dein Backup komplett aus dem Kopf streichen.
Dann nimm lieber einen einfachen Server, mit der gleichen Ausstattung wie ein NAS (zu ähnlichem Preis) und installiere da den PBS drauf. Damit gewinnst du so viel mehr Datensicherheit als bei jeder NAS Lösung. Das wäre Prio1 und die bessere Performance ist dann der Bonus.

 

[Johannes S]

Eine Bastellösung à la PBS in Container auf einer NAS möchte ich auch nicht. Es sollte schon hinterher verlässlich funktionieren.

Außerdem hätte ich dann nur Vorteile wenn ich auf den Speicher einer NAS zugreifen möchte. Sobald ich aber eine weitere NAS als weitern Datastore einbinden möchte hab ich wieder keinen Vorteil.

Kommt aufs Setup an: Du könntest auf der zweiten NAS ja auch eine PBS-VM aufsetzen und beide dann mit PBS native sync-Funktion miteinander synchronisieren lassen.

 

[S3v|\|]

Die 2 DFS Server sollten natürlich getrennt liegen, aber im Backup Datastore würden die dedupliziert werden

Nur für mich zum Verständniss:
wenn die zwei Server auf zwei unterschiedliche Datastores gesichert werden: Werden die dennoch dedupliziert?
Was ist wenn ein Datastore ausfällt? Sind dann alle Sicherungen beschädigt, da die Hälfte fehlt?

 

[Falk R.]

Nur für mich zum Verständniss:
wenn die zwei Server auf zwei unterschiedliche Datastores gesichert werden: Werden die dennoch dedupliziert?
Was ist wenn ein Datastore ausfällt? Sind dann alle Sicherungen beschädigt, da die Hälfte fehlt?

Wenn du auf verschiedene Datastores sicherst, gibts kein Dedup. Sind es verschiedene Namespaces im Datastore, gibts Dedup.
Du solltest eh immer eine Backupkopie machen. Es gibt die Simple 3-2-1 Regel.
3 Datenkopien - Produktiv, Backup, SekundärBackup
2 Medien - Medienbruch ( Nicht klar definiert, Kann SSD/HDD, Disk/Tape oder Disk/Objektspeicher sein)
1 Kopie offsite - Zweiter Backupserver in anderem Standort, Tapes wegtragen oder in die Cloud

Ach ja, bei lokal PBS habe ich noch nie Datenverlust gehabt und dafür machst du ja den Verify.
Theoretisch kann man auch Backups reparieren, wenn der defekte Chunk noch auf einem anderen PBS in heile schlummert.

 

[S3v|\|]

Da du beim PBS auch noch den Performancenachteil des NFS hast, solltest du das Thema NAS (egal was für eins) für dein Backup komplett aus dem Kopf streichen.

Wie sieht es aus, wenn ich ein dem PBS ein LUN über iSCSI zur Verfügung stelle?

 

[Falk R.]

Wie sieht es aus, wenn ich ein dem PBS ein LUN über iSCSI zur Verfügung stelle?

Das ist ein Blockspeicher, da ist das Dateisystem immer noch lokal. Aber bitte kein NAS mit iSCSI nutzen. Da hat man im NAS ein Dateisystem und legt da eine große Datei drauf, die als iSCSI LUN weiter gereicht wird. Das ist immer per Design langsam. Dürfte stabiler laufen als NFS, aber trotzdem umständlich und teuer.
Du willst doch eh von NAS weg, warum nicht den simplen Weg gehen?

 

[S3v|\|]

Du willst doch eh von NAS weg, warum nicht den simplen Weg gehen?

Ich möchte nur von der QNAP-NAS weg. Wir haben eine mit Dual-Controller - sollte eigentlich doppelt ausfallsicher sein - unsere Erfahrung wir haben viermal so viele Probleme mit asynchronen Datenbanken zwischen den zwei Controlern. Daher die Idee mit der TrueNAS.

Warum? - Wahrscheinlich eine Kopfsache. Vielleicht denke ich da auch zu verknotet. Folgende Punkte schwirren mir immer im Kopf:
- Wenn der Speicher zu knapp wird, dann kann ich bei externen einfach ein weiteren Datastore hinzufügen und die zwei PVE Cluster getrennt sichern
- wenn die zwei Cluster getrennt gesichert werden und ein Speicher defekt ist, dann hab ich zur Sicherheit noch den zweiten
- Wenn ich zu viel Speicher hab, dann liegt der ungenutzt rum - bei einer NAS kann ich den zumindest teilweise noch nutzen
- bei einer NAS übernimmt das OS die Überprüfung der Festplatten und meldet sich rechtzeitig bei mir und sag genau, welche Platte ein Problem hat - beim PBS hab ich keinerlei Erfahrung mit der Festplatten- und Filesystemverwaltung (ich hab mich bisher erst mehr schlecht als recht in ZFS-Grundlagen eingearbeitet)
- ...

Wahrscheinlich spielt auch die Gesammtsituation etwas mit:
Ich bin kein gelernter Sysadmin. Ich arbeite für ein kleines Ingenieurbüro und betreue lokal die EDV. Vor 1 1/2 Jahren haben wir den externen EDV-Support gewechselt. Wir möchten auch so viel wie möglich wieder intern erledigen. Ein Langzeitziele ist auch weg von MS und proprietären Systemen zu kommen. (Ist aber auf Grund der Mitarbeiter zum großen Teil Wunschdenken.) In diesem Zuge sind wir von MS Hyper-V auf Proxmox umgestiegen. Zusätzlich haben wir einen Teil unserer Infrastruktur in ein Rechenzentrum ausgelagert (ursprünglich als produktiv im Homeoffice geplant mit sync ins Büro - inzwischen haupsächlich aber nur als Sicherheit verwendet). Vorher hatten wir zwei DFS-Fileserver hier lokal, die die Daten auf iSCSI ausgelagert hatten. Da dies auch zu mehreren Fehlern geführt hatte (war zum Teil wohl auch falsch konfiguriert) haben wir die Daten wieder auf eine virtuelle Festplatte in der VM verschoben.
Die Sicherung bisher lief über Veeam auf eine NAS und von dort aus auf ein Tape. Hat in der HyperV Umgebung recht gut funktioniert. Unter Proxmox haben wir bisher noch nicht geschafft einer vernünftige Veeam-Sicherung zu erstellen. (Wird zwar inzwischen von Veeam auch unterstütz, aber da sind die auch noch in der Entwicklungsphase).
Langfristig ist geplant die VMs mit PBS zu sichern und Fileserver, MS-SQL und Exchange zusätzlich mit Veeam, da es VSS kann - Da kann man leichter auf einzelne Elemente zugreifen. Ausserdem kann man dort auch leichter einzelne Tapesicherungen erstellen lassen. Bei PBS gibt es meines Wissens nach keine Möglichkeit einzelne Sicherungen zu exportieren.