36
ISCSI ReFS LUN plötzlich RAW Format
Hallo zusammen,
ich stehe hier vor einem kleinen GAU. Klein deshalb, weile es sich zum Glück um ein Copy-System handelt.
Nichtsdestotrotz wären im Zweifel ca. 70 TB Daten weg, und die wieder zu kopieren ... allein der Zeitfaktor ist schon ätzend^10
Was ist passiert: ein Windows Server 2019 LTSB 1809/17763 erhält per iSCSI zwei 100TB LUNs von einem Synology NAS um dort Kopien von Daten abzulegen. Dateisystem ist ReFS.
Aus Gründen die mir unbekannt sind, ist das Server-System am letzten Wochenende in der Nacht bei einem Update des XDR Clients gecrasht. So liest sich zumindest das Eventlog. Dabei wurde wohl LUN 2 beschädigt
Seit dem schaut es in der Datenträgerverwaltung so aus, dass die zweite LUN nun als RAW angezeigt wird und Zugriff nicht möglich ist.
Offline und Online nehmen hat nichts verändert. Also mal mit CheckDisk versucht, aber da erhalte ich nur den Hinweis, dass ReFS nicht repariert werden müsse.
Mir sagt das erstmal, dass das Dateisystem offenbar noch da ist und erkannt wird. Aber Windows es nicht mehr einbinden kann.
Noch jemand mit Ideen und Tipps? Wäre Dankbar.
ich stehe hier vor einem kleinen GAU. Klein deshalb, weile es sich zum Glück um ein Copy-System handelt.
Nichtsdestotrotz wären im Zweifel ca. 70 TB Daten weg, und die wieder zu kopieren ... allein der Zeitfaktor ist schon ätzend^10
Was ist passiert: ein Windows Server 2019 LTSB 1809/17763 erhält per iSCSI zwei 100TB LUNs von einem Synology NAS um dort Kopien von Daten abzulegen. Dateisystem ist ReFS.
Aus Gründen die mir unbekannt sind, ist das Server-System am letzten Wochenende in der Nacht bei einem Update des XDR Clients gecrasht. So liest sich zumindest das Eventlog. Dabei wurde wohl LUN 2 beschädigt
Seit dem schaut es in der Datenträgerverwaltung so aus, dass die zweite LUN nun als RAW angezeigt wird und Zugriff nicht möglich ist.
Offline und Online nehmen hat nichts verändert. Also mal mit CheckDisk versucht, aber da erhalte ich nur den Hinweis, dass ReFS nicht repariert werden müsse.
Mir sagt das erstmal, dass das Dateisystem offenbar noch da ist und erkannt wird. Aber Windows es nicht mehr einbinden kann.
Noch jemand mit Ideen und Tipps? Wäre Dankbar.
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 42732437412
Url: https://administrator.de/forum/iscsi-refs-lun-ploetzlich-raw-format-42732437412.html
Ausgedruckt am: 30.12.2024 um 18:12 Uhr
36 Kommentare
Neuester Kommentar
an der Netzwerkconfig wurde zwischenzeitlich nichts verändert?
Hast du Fehlerhafte Pakete auf den Switchen?
Was sagt das Syno Disk Tool log?
Hast du Fehlerhafte Pakete auf den Switchen?
Was sagt das Syno Disk Tool log?
Danke für Deine Antwort.
Der Server ist, von regelmäßigen Windows Updates abgesehen, unverändert in Betrieb.
Da LUN 1 von 2 problemlos arbeitet und auf der Syno auch alles in Ordnung ist, ich auch keine Fehlerhaften Einträge dort im LOG sehe, gehe ich davon aus, dass da alles okay ist.
EDIT - noch ergänzend: Die LUNs sind über 1 Target angebunden und kommunizieren somit über den gleichen Netzwerkpfad.
Der Server ist, von regelmäßigen Windows Updates abgesehen, unverändert in Betrieb.
Da LUN 1 von 2 problemlos arbeitet und auf der Syno auch alles in Ordnung ist, ich auch keine Fehlerhaften Einträge dort im LOG sehe, gehe ich davon aus, dass da alles okay ist.
EDIT - noch ergänzend: Die LUNs sind über 1 Target angebunden und kommunizieren somit über den gleichen Netzwerkpfad.
Schon mal jemand mit dem ReFSutil gearbeitet?
https://learn.microsoft.com/de-de/windows-server/administration/windows- ...
da gibt es u.a. Optionen für
fixboot
leak
salvage
triage
Von Verständnis würde ich ein refsutil leak Y: versuchen.
https://learn.microsoft.com/de-de/windows-server/administration/windows- ...
da gibt es u.a. Optionen für
fixboot
leak
salvage
triage
Von Verständnis würde ich ein refsutil leak Y: versuchen.
Die offizielle syno Lösung: https://kb.synology.com/de-de/DSM/tutorial/What_should_I_do_when_iSCSI_L ...
vielleicht kannst du per ssh auf die syno und dort testdisk installieren.. möglich wärs ja prinzipiell
vielleicht kannst du per ssh auf die syno und dort testdisk installieren.. möglich wärs ja prinzipiell
Danke Dir. Den Artikel habe ich natürlich auch gefunden und mit dem darin erwähnten CheckDisk habe ich es ja versucht. War ja Ergebnislos.
Hier noch das Event-Log zum ReFS:
Volume Y: ist als ReFS formatiert, es kann jedoch von ReFS nicht eingebunden werden. Von ReFS wurde der Status "Eine Objekt-ID wurde nicht in der Datei gefunden." erkannt.
Ich werde damit mal weiter forschen.
Hier noch das Event-Log zum ReFS:
Volume Y: ist als ReFS formatiert, es kann jedoch von ReFS nicht eingebunden werden. Von ReFS wurde der Status "Eine Objekt-ID wurde nicht in der Datei gefunden." erkannt.
Ich werde damit mal weiter forschen.
ich hab gerade keine syno mit iscsi zur hand aber ich bin relativ sicher das es dort irgendwo im syno menü einen lun check gibt. Den Raid Test hast du gemacht?
Würde da per iscsi anbindung nix mehr testen, das macht alles nur schlimmer. Lieber erstmal direkt auf der syno.
Würde da per iscsi anbindung nix mehr testen, das macht alles nur schlimmer. Lieber erstmal direkt auf der syno.
Kann die Syno überhaupt selbst etwas mit ReFS anfangen? Wenn nein, dann helfen die check Tools dort sehr wenig.
Ich vermute das das Dateisystem echt etwas abbekommen hat. Aber ohne tieferes wissen würde ich da ohne Support nix machen.
Warum sind die LUNs eigentlich ReFS formatiert? Liegen dort VMs drauf?
Ich vermute das das Dateisystem echt etwas abbekommen hat. Aber ohne tieferes wissen würde ich da ohne Support nix machen.
Warum sind die LUNs eigentlich ReFS formatiert? Liegen dort VMs drauf?
1
Wir haben so Syno/iSCSI Kombis mehrfach im Einsatz und bisher keine Problem gehabt. Allerdings ist da auch kein Server mal gecrasht.
Da die Syno alles Grün meldet, zudem der Server und nicht die Syno den Crash hatte, CheckDisk auf dem Server ein ReFS erkennt und auch noch der Windows Log Eintrag recht eindeutig ist, sehe ich das Problem aktuell eher beim Dateisystem.
Wie ich inzw. weiß, gab es da seiten MS auch mal ein KB, dass für exakt so einen Fehler verantwortlich zeichnete, welches bei mir aber nicht installiert ist. Das war vor der Zeit dieses Servers. Gibt da auf Borncity einen entsprechenden Eintrag.
Da die Syno alles Grün meldet, zudem der Server und nicht die Syno den Crash hatte, CheckDisk auf dem Server ein ReFS erkennt und auch noch der Windows Log Eintrag recht eindeutig ist, sehe ich das Problem aktuell eher beim Dateisystem.
Wie ich inzw. weiß, gab es da seiten MS auch mal ein KB, dass für exakt so einen Fehler verantwortlich zeichnete, welches bei mir aber nicht installiert ist. Das war vor der Zeit dieses Servers. Gibt da auf Borncity einen entsprechenden Eintrag.
Kann die Syno überhaupt selbst etwas mit ReFS anfangen?
Die stellt ja nur die LUN Bereit. Der ist es Egal, ob die mit NTFS oder ReFS formatiert ist.
Warum sind die LUNs eigentlich ReFS formatiert?
Veeam besteht darauf. Ist ein Copy Store fürs Backup.
Zitat von @pcpanik:
Wie ich inzw. weiß, gab es da seiten MS auch mal ein KB, dass für exakt so einen Fehler verantwortlich zeichnete, welches bei mir aber nicht installiert ist. Das war vor der Zeit dieses Servers. Gibt da auf Borncity einen entsprechenden Eintrag.
Wie ich inzw. weiß, gab es da seiten MS auch mal ein KB, dass für exakt so einen Fehler verantwortlich zeichnete, welches bei mir aber nicht installiert ist. Das war vor der Zeit dieses Servers. Gibt da auf Borncity einen entsprechenden Eintrag.
Das hatte eine einfache Ursache im Versions-Check. Deine Situation bzw. Fehlermeldung deutet darauf hin, dass mindestens die Object-ID-Table beschädigt ist. Die kann zur Datenwiederherstellung übersprungen werden (wahrscheinlich macht auch ReFSutil das), aber das Kopieren der Daten von diesem Volume ist bei vorhendenem Backup wahrscheinlich nicht zielführend. Jedenfalls ein Fall für Datenwiederherstellung oder Backup.
Ein Veeam-Repo an einem Windows-Server soll ReFS-formatiert werden. Die Konstruktion an sich, ReFS über iSCSI auf eine Synology, ist aber Harakiri und wurde sicher nicht von Veeam nahegelegt. Das ist ein Paradebeispiel für die Fixierung auf Low-End-NAS von QNAP oder Synology in der KMU-"Beratung". Hier wurden dreistellige TB in eine Lösung investiert, die architektonisch überhaupt keinen Sinn ergibt.
Grüße
Richard
Moin Richard,
so gerne ich jetzt bei dieser Klopfaktion auch mitmachen würde, da ich die QNAP's & Co im professionellen Umfeld wohl genau so gut leiden kann wie auch du, muss ich diese dieses Mal doch eher in Schutz nehmen, da die Probleme des TO's nicht wirklich etwas mit dem beiden SoHo-NAS Hersteller zu tun haben, sondern ganz sicher mit diesem bescheidenen ReFS.
Denn dieses Dateisystem ist meiner Ansicht nach höchstens für lokale Datenträger geeignet und auch nur dann, wenn du darauf keine kritischen Daten abgelegt werden. Im Enterprise Umfeld und vor allem bei einer CVS wo ein SAN als Backend dran hängt, sollte man es nicht wirklich verwenden.
Uns ist bei einem Kunden schon vor Jahren aufgrund von iSCSI Übertragungsproblemen zwei mal eine ReFS formatierte LUN mit > 150TB die von einem enterprise SAN bereitgestellt wurde um die Ohren geflogen und seit dem verwenden wir ReFS überhaupt nicht mehr.
Und warum man ReFS bei einem CVS nicht benutzen sollte ...
Warum ihr keine ReFS Formatierung für CSVs verwenden solltet, die von einem SAN bereitgestellt werden
... war übrigens einer meiner ersten Beiträge hier. 🙃
Gruss Alex
Ein Veeam-Repo an einem Windows-Server soll ReFS-formatiert werden. Die Konstruktion an sich, ReFS über iSCSI auf eine Synology, ist aber Harakiri und wurde sicher nicht von Veeam nahegelegt. Das ist ein Paradebeispiel für die Fixierung auf Low-End-NAS von QNAP oder Synology in der KMU-"Beratung". Hier wurden dreistellige TB in eine Lösung investiert, die architektonisch überhaupt keinen Sinn ergibt.
so gerne ich jetzt bei dieser Klopfaktion auch mitmachen würde, da ich die QNAP's & Co im professionellen Umfeld wohl genau so gut leiden kann wie auch du, muss ich diese dieses Mal doch eher in Schutz nehmen, da die Probleme des TO's nicht wirklich etwas mit dem beiden SoHo-NAS Hersteller zu tun haben, sondern ganz sicher mit diesem bescheidenen ReFS.
Denn dieses Dateisystem ist meiner Ansicht nach höchstens für lokale Datenträger geeignet und auch nur dann, wenn du darauf keine kritischen Daten abgelegt werden. Im Enterprise Umfeld und vor allem bei einer CVS wo ein SAN als Backend dran hängt, sollte man es nicht wirklich verwenden.
Uns ist bei einem Kunden schon vor Jahren aufgrund von iSCSI Übertragungsproblemen zwei mal eine ReFS formatierte LUN mit > 150TB die von einem enterprise SAN bereitgestellt wurde um die Ohren geflogen und seit dem verwenden wir ReFS überhaupt nicht mehr.
Und warum man ReFS bei einem CVS nicht benutzen sollte ...
Warum ihr keine ReFS Formatierung für CSVs verwenden solltet, die von einem SAN bereitgestellt werden
... war übrigens einer meiner ersten Beiträge hier. 🙃
Gruss Alex
2
Hi Richard,
ich befürchte, da kommst du um ein Re-Format nicht drum herum. Selbst, wenn hier irgendein Rettungstool das Volume nochmals online bekommt - ich hätte hier Bauchschmerzen bzgl. der Datenintegrität, das müsste ohnehin alles geprüft werden, ansonsten könntest du bei einem Restorefall eventuell große Augen machen.
Generell habe ich noch im Kopf, dass ReFS auf SAN / NAS nicht supported sei, sondern nur in Verbindung mit lokalen Disks. Habe schon mehrfach Berichte gelesen, dass ReFS-Volumes auf SAN/NAS gerne (bspw. durch kurze Verbindungsunterbrechungen) korrupt gegangen sind.
ReFS hatte ich bisher nur in Verbindung mit Veeam im Einsatz, da hatte ich persönlich (glücklicherweise) keine Probleme.
Allerdings habe ich einige Setups in den letzten Jahren auf ein Immutable Repository auf Basis von Ubuntu und XFS umgestellt - im Vergleich zu ReFS hat XFS hier einen deutlich besseren Ruf.
Das hatte ich auch schon in Verbindung mit Synologys eingerichtet - nativ geht das nicht, aber man kann auf der Synology eine VM mit Ubuntu und einer lokalen Disk anlegen, welche dann auf dem RAID liegt.
Keineswegs ist das ein Ersatz für einen vollwertigen Backupserver, aber in meinen Augen ein legitimer Mittelweg für eine Offsite Copy o.ä.
Viele Grüße
mxrecord
ich befürchte, da kommst du um ein Re-Format nicht drum herum. Selbst, wenn hier irgendein Rettungstool das Volume nochmals online bekommt - ich hätte hier Bauchschmerzen bzgl. der Datenintegrität, das müsste ohnehin alles geprüft werden, ansonsten könntest du bei einem Restorefall eventuell große Augen machen.
Generell habe ich noch im Kopf, dass ReFS auf SAN / NAS nicht supported sei, sondern nur in Verbindung mit lokalen Disks. Habe schon mehrfach Berichte gelesen, dass ReFS-Volumes auf SAN/NAS gerne (bspw. durch kurze Verbindungsunterbrechungen) korrupt gegangen sind.
ReFS hatte ich bisher nur in Verbindung mit Veeam im Einsatz, da hatte ich persönlich (glücklicherweise) keine Probleme.
Allerdings habe ich einige Setups in den letzten Jahren auf ein Immutable Repository auf Basis von Ubuntu und XFS umgestellt - im Vergleich zu ReFS hat XFS hier einen deutlich besseren Ruf.
Das hatte ich auch schon in Verbindung mit Synologys eingerichtet - nativ geht das nicht, aber man kann auf der Synology eine VM mit Ubuntu und einer lokalen Disk anlegen, welche dann auf dem RAID liegt.
Keineswegs ist das ein Ersatz für einen vollwertigen Backupserver, aber in meinen Augen ein legitimer Mittelweg für eine Offsite Copy o.ä.
Viele Grüße
mxrecord
Moin @mxrecord,
jup, stand jetzt steht +- genau das in der MS-Doku zu ReFS.
Es war jedoch ein sehr langer und auch mühseliger Weg, bis Microsoft den Murks den es vorher in den entsprechenden Dokus geschrieben hat, korrigiert hat. Denn am Anfang, hat MS jahrelang ReFS für SAN's sogar ausdrücklich empfohlen. 😔
Gruss Alex
Generell habe ich noch im Kopf, dass ReFS auf SAN / NAS nicht supported sei, sondern nur in Verbindung mit lokalen Disks.
jup, stand jetzt steht +- genau das in der MS-Doku zu ReFS.
Es war jedoch ein sehr langer und auch mühseliger Weg, bis Microsoft den Murks den es vorher in den entsprechenden Dokus geschrieben hat, korrigiert hat. Denn am Anfang, hat MS jahrelang ReFS für SAN's sogar ausdrücklich empfohlen. 😔
Gruss Alex
Zitat von @MysticFoxDE:
so gerne ich jetzt bei dieser Klopfaktion auch mitmachen würde, da ich die QNAP's & Co im professionellen Umfeld wohl genau so gut leiden kann wie auch du, muss ich diese dieses Mal doch eher in Schutz nehmen, da die Probleme des TO's nicht wirklich etwas mit dem beiden SoHo-NAS Hersteller zu tun haben...
so gerne ich jetzt bei dieser Klopfaktion auch mitmachen würde, da ich die QNAP's & Co im professionellen Umfeld wohl genau so gut leiden kann wie auch du, muss ich diese dieses Mal doch eher in Schutz nehmen, da die Probleme des TO's nicht wirklich etwas mit dem beiden SoHo-NAS Hersteller zu tun haben...
Das nicht, aber das NAS lässt nur mehr oder minder schlechte Optionen zu:
- ReFS über iSCSI mit dem bekannten Ausgang,
- das für Veeam nicht ideale NTFS-Repo, wieder mit iSCSI-Gefummel,
- ein SMB- oder NFS-Repo, dessen Probleme auf solchen NAS oft die Vorgeschichte zu iSCSI-Workarounds an Veeam-Servern bilden.
Moin Richard,
auch daran ist nicht wirklich die NAS schuld, denn per iSCSI stellt es, wie ein SAN auch, lediglich ein Block-LUN bereit und wie dieses dann formatiert wird, entscheidet der entsprechende Admin ... aber der hat wegen dem ReFS meiner Ansicht nach auch nicht wirklich Schuld, da er damit lediglich den Empfehlungen von Veeam folgt.
Wenn ich mich richtig erinnere, dann meckert Veeam mittlerweile sogar aktiv rum, wenn die Backup-LUN nicht ReFS formatiert ist. 😔
Wir benutzen selber seit einiger Zeit wieder vorwiegend SMB-Repo's für die Sicherung per Veeam, weil dies zumindest bei Hyper-V Cluster, einige Vorteile mit sich bring, wie z.B. die Tatsache, dass in dem Fall alle Hosts direkt auf das Backup-Storage schreiben und von diesem auch lesen können, was per iSCSI so nicht ganz einfach ist.
Gruss Alex
Das nicht, aber das NAS lässt nur mehr oder minder schlechte Optionen zu:
- ReFS über iSCSI mit dem bekannten Ausgang,
auch daran ist nicht wirklich die NAS schuld, denn per iSCSI stellt es, wie ein SAN auch, lediglich ein Block-LUN bereit und wie dieses dann formatiert wird, entscheidet der entsprechende Admin ... aber der hat wegen dem ReFS meiner Ansicht nach auch nicht wirklich Schuld, da er damit lediglich den Empfehlungen von Veeam folgt.
* das für Veeam nicht ideale NTFS-Repo, wieder mit iSCSI-Gefummel
Wenn ich mich richtig erinnere, dann meckert Veeam mittlerweile sogar aktiv rum, wenn die Backup-LUN nicht ReFS formatiert ist. 😔
* ein SMB- oder NFS-Repo, dessen Probleme auf solchen NAS oft die Vorgeschichte zu iSCSI-Workarounds an Veeam-Servern bilden.
Wir benutzen selber seit einiger Zeit wieder vorwiegend SMB-Repo's für die Sicherung per Veeam, weil dies zumindest bei Hyper-V Cluster, einige Vorteile mit sich bring, wie z.B. die Tatsache, dass in dem Fall alle Hosts direkt auf das Backup-Storage schreiben und von diesem auch lesen können, was per iSCSI so nicht ganz einfach ist.
Gruss Alex
1Wenn ich mich richtig erinnere, dann meckert Veeam mittlerweile sogar aktiv rum, wenn die Backup-LUN nicht ReFS formatiert ist.
Das ist korrekt, und ich sehe nicht, was ich hätte anders machen sollen. Das läuft seit einigen Jahren so, stressfrei.
Tatsächlich wäre, auch aus Sicherheitsgründen, SMB die andere Option und etwas, wo ich eh komplett wieder hin will. Wenn dieses ReFS Repo kaputt ist, wäre dafür jetzt der Wechsel denkbar.
Über verschüttete Milch zu weinen und Syno Qnap gebashe hilft da im Nachgang auch keinen Deut.
Mit begrenzten menschlichen und finanziellen Ressourcen betreiben wir diverse Synos mit mehreren Hundert TB mit mehreren HA Clustern schon viele Jahre ziemlich erfolgreich und Stressfrei. Sowohl als NAS, LUNs im VM Umfeld als auch als Storage für Datensicherung. Es gab mal ärger mit DSM 6.2 und dem Schwenken des Clusters mit aktivem iSCSI, das ist seit DSM 7 aber alles Geschichte. Und wir hatten mal ärger mit nem Shelf, das wurde aber auf Garantie binnen 24h ersetzt. Die Einrichtung eines SA3400 Clusters zickte anfangs etwas rum, aber auch das ließ sich beheben. Wenn ich mir überlege, was der Dienstleister für ein Theater hatte, unser neues IBM Storage für die Virtuelle Welt in Betrieb zu nehmen, war das aber Kindergarten dagegen ... ist natürlich chic, das IBM Storage, das aber wieder FC vorschreibt ...
In den letzten 6 Jahren ist nun 1x ein ReFS kaputt... ist zu Deutsch "Schei*e" und sicher eines zu viel, aber nun versuchen die Syno dafür verantwortlich zu machen, wenn durch ein XDR Update der Windows Server crasht und seinen ReFS Table zerlegt, sehe ich einfach nicht.
Nun gut, ich mache das Volume platt, löse die LUN auf, mache ein SMB Repo daraus und lasse Veeam alles rüber kopieren. Wird ein paar Tage dauern.
Danke für eure Beiträge
1
der hier kann es angeblich lesen: https://www.easeus.de/ressource/dateien-auf-refs-partition-wiederherstel ...
Moin @pcpanik,
eigentlich hast du alles richtig gemacht, da du dich an die Vorgaben der Hersteller gehalten hast.
Leider kann man viele davon mittlerweile noch nicht mal den Hassen zum fressen geben, da diese leider zunehmender entweder unvollständig oder gar irreführend sind. 😔😭
Schau dir mal die Infortrend Storages an ...
https://www.infortrend.com/
... die kosten bei einer ähnlichen Bestückung nicht viel mehr als eine vergleichbare QNAP oder SYNO, liefern jedoch deutlich mehr Bums und sind zudem zu 100% auf Enterprise ausgelegt und nicht auch auf Privatanwender. 😉
Wie schon geschrieben, dein Problem hat nichts mit der NAS tu tun, daher musst du dir diesbezüglich auch keine Vorwürfe machen oder einreden lassen. Einem unserer Kunden ist wie gesagt dasselbe passiert und zwar zwei Mal hintereinander bei einem >80K Backup-SAN (ca. 400 TB). Nach dem zweiten Mal haben wir die entsprechende LUN mit NTFS formatiert und seit dem läuft das Backup bei diesem Kunden, schon seit einigen Jahren ohne Probleme und ohne das was anderes umgestellt wurde.
Gruss Alex
Das ist korrekt, und ich sehe nicht, was ich hätte anders machen sollen.
eigentlich hast du alles richtig gemacht, da du dich an die Vorgaben der Hersteller gehalten hast.
Leider kann man viele davon mittlerweile noch nicht mal den Hassen zum fressen geben, da diese leider zunehmender entweder unvollständig oder gar irreführend sind. 😔😭
Mit begrenzten menschlichen und finanziellen Ressourcen betreiben wir diverse Synos mit mehreren Hundert TB mit mehreren HA Clustern schon viele Jahre ziemlich erfolgreich und Stressfrei. Sowohl als NAS, LUNs im VM Umfeld als auch als Storage für Datensicherung. Es gab mal ärger mit DSM 6.2 und dem Schwenken des Clusters mit aktivem iSCSI, das ist seit DSM 7 aber alles Geschichte. Und wir hatten mal ärger mit nem Shelf, das wurde aber auf Garantie binnen 24h ersetzt. Die Einrichtung eines SA3400 Clusters zickte anfangs etwas rum, aber auch das ließ sich beheben. Wenn ich mir überlege, was der Dienstleister für ein Theater hatte, unser neues IBM Storage für die Virtuelle Welt in Betrieb zu nehmen, war das aber Kindergarten dagegen ... ist natürlich chic, das IBM Storage, das aber wieder FC vorschreibt ...
Schau dir mal die Infortrend Storages an ...
https://www.infortrend.com/
... die kosten bei einer ähnlichen Bestückung nicht viel mehr als eine vergleichbare QNAP oder SYNO, liefern jedoch deutlich mehr Bums und sind zudem zu 100% auf Enterprise ausgelegt und nicht auch auf Privatanwender. 😉
In den letzten 6 Jahren ist nun 1x ein ReFS kaputt... ist zu Deutsch "Schei*e" und sicher eines zu viel, aber nun versuchen die Syno dafür verantwortlich zu machen, wenn durch ein XDR Update der Windows Server crasht und seinen ReFS Table zerlegt, sehe ich einfach nicht.
Wie schon geschrieben, dein Problem hat nichts mit der NAS tu tun, daher musst du dir diesbezüglich auch keine Vorwürfe machen oder einreden lassen. Einem unserer Kunden ist wie gesagt dasselbe passiert und zwar zwei Mal hintereinander bei einem >80K Backup-SAN (ca. 400 TB). Nach dem zweiten Mal haben wir die entsprechende LUN mit NTFS formatiert und seit dem läuft das Backup bei diesem Kunden, schon seit einigen Jahren ohne Probleme und ohne das was anderes umgestellt wurde.
Gruss Alex
1
Danke, dann gehe ich wohl zwecks einfachheit den Weg mit NTFS.
Grundsätzlich sind wir mit den Synos zufrieden, insbesondere da diese sehr felxibel eingesetzt werden können.
U.a. betreiben wir damit auch die Surveillance.
Wir haben für die Virtuelle Welt ein neues IBM Flash Storage.
Da macht es wenig Sinn sich noch einen 3. Player anzusehen.
Aber Danke für den Hinweis in jedem Fall! Tellerand gucken ist immer gut.
Grundsätzlich sind wir mit den Synos zufrieden, insbesondere da diese sehr felxibel eingesetzt werden können.
U.a. betreiben wir damit auch die Surveillance.
Wir haben für die Virtuelle Welt ein neues IBM Flash Storage.
Da macht es wenig Sinn sich noch einen 3. Player anzusehen.
Aber Danke für den Hinweis in jedem Fall! Tellerand gucken ist immer gut.
Also ReFS auf ISCSI wird von Veeam nicht supported. Mittlerweile sogar davon abgeraten.
Anfangs hat Microsoft auch ReFS nur für lokale Storages unterstützt. Nur weil man es formatieren kann, heißt es nicht, dass es problemlos funktioniert.
Ps.: Ein physischer Backup Server mit 16 oder 24 Bays und HW RaidController für Veeam Backups kostet nicht mehr, als ein vergleichesbares QNAP oder eine Syno. Noch dazu kannst du dort auch die Immutable Backups besser umsetzen.
Letztes Jahr haben wir unser QNAP für die Copy Backups ( nichts Primary) gegen einen 24 Bay von TK ersetzt
Anfangs hat Microsoft auch ReFS nur für lokale Storages unterstützt. Nur weil man es formatieren kann, heißt es nicht, dass es problemlos funktioniert.
Ps.: Ein physischer Backup Server mit 16 oder 24 Bays und HW RaidController für Veeam Backups kostet nicht mehr, als ein vergleichesbares QNAP oder eine Syno. Noch dazu kannst du dort auch die Immutable Backups besser umsetzen.
Letztes Jahr haben wir unser QNAP für die Copy Backups ( nichts Primary) gegen einen 24 Bay von TK ersetzt
Moin @pcpanik,
du hast mich glaube ich etwas missverstanden.
In dem Fall den ich zuletzt beschrieben habe, sprich, wo die ReFS LUN um die Ohren geflogen ist, hatte der Kunde nur ein Backup-SAN welches per iSCSI an die Veeam VM gemountet war und in diesem Fall konnten wir lediglich nur die LUN mit NTFS anstelle von ReFS zu formatieren und das hat dann auch zum Glück geholfen.
Du hast jedoch ein NAS als Backup Ziel und darauf kannst du direkt eine SMB Freigabe für die Veeam Backups anlegen, und diese als Ziel beim Veeam hinterlegen und schon ist der Fisch geputzt und du musst dich auch nicht mit NTFS oder ReFS herumschlagen. 😉
Ja, OK, wenn das Filesystem der NAS crasht, dann hast du auch ein Problem, die sind jedoch viel Wiederstandfähiger wie zumindest das ReFS bei Windows.
genau so war das auch gemeint. 😉
Gruss Alex
Danke, dann gehe ich wohl zwecks einfachheit den Weg mit NTFS.
du hast mich glaube ich etwas missverstanden.
In dem Fall den ich zuletzt beschrieben habe, sprich, wo die ReFS LUN um die Ohren geflogen ist, hatte der Kunde nur ein Backup-SAN welches per iSCSI an die Veeam VM gemountet war und in diesem Fall konnten wir lediglich nur die LUN mit NTFS anstelle von ReFS zu formatieren und das hat dann auch zum Glück geholfen.
Du hast jedoch ein NAS als Backup Ziel und darauf kannst du direkt eine SMB Freigabe für die Veeam Backups anlegen, und diese als Ziel beim Veeam hinterlegen und schon ist der Fisch geputzt und du musst dich auch nicht mit NTFS oder ReFS herumschlagen. 😉
Ja, OK, wenn das Filesystem der NAS crasht, dann hast du auch ein Problem, die sind jedoch viel Wiederstandfähiger wie zumindest das ReFS bei Windows.
Aber Danke für den Hinweis in jedem Fall! Tellerand gucken ist immer gut.
genau so war das auch gemeint. 😉
Gruss Alex
Moin @tech-flare,
ja, weil der TO mit seinem Problem bei weitem nicht der einzige ist.
Und hätte Veeam ReFS anständig getestet und nicht nur stumpf die Empfehlung von MS übernommen, dann wäre ein solches Schlammassel eventuell auch nicht passiert.
Ein von einem SAN gemountetes LUN ist aber für das Windows quasi wie ein "lokales Storage" oder durch einen lokalen RAID-Kontroller bereitgestellte LUN.
Gruss Alex
Also ReFS auf ISCSI wird von Veeam nicht supported. Mittlerweile sogar davon abgeraten.
ja, weil der TO mit seinem Problem bei weitem nicht der einzige ist.
Und hätte Veeam ReFS anständig getestet und nicht nur stumpf die Empfehlung von MS übernommen, dann wäre ein solches Schlammassel eventuell auch nicht passiert.
Anfangs hat Microsoft auch ReFS nur für lokale Storages unterstützt. Nur weil man es formatieren kann, heißt es nicht, dass es problemlos funktioniert.
Ein von einem SAN gemountetes LUN ist aber für das Windows quasi wie ein "lokales Storage" oder durch einen lokalen RAID-Kontroller bereitgestellte LUN.
Gruss Alex
Also ReFS auf ISCSI wird von Veeam nicht supported. Mittlerweile sogar davon abgeraten.
Ich lass das mal so im Raum stehen, was deren Software einem Admin dazu sagt, wenn man es einrichtet.
Die scheint ja nicht zu prüfen, ob es sich um ein per iSCSI eingebundes Volume handelt.
Von "davon wird abgeraten" erkennt man in dem Moment mal nichts.
Was den Storage angeht, da führen viele Wege nach Rom.
Mir ist es lieber, der ist vom BS separiert.
Und ich werde zukünftig wieder auf Freigaben setzen.
Lokaler und per iSCSI eingebundener Storage lässt sich meiner Auffasung nach zudem zu leicht kompromittieren.
So, die Copy Jobs legen bereits neue Full Backups an.... jetzt heißt es abwarten.
In dem Fall den ich zuletzt beschrieben habe, sprich, wo die ReFS LUN um die Ohren geflogen ist, hatte der Kunde nur ein Backup-SAN welches per iSCSI an die Veeam VM gemountet war und in diesem Fall konnten wir lediglich nur die LUN mit NTFS anstelle von ReFS zu formatieren und das hat dann auch zum Glück geholfen.
Ich habe vor im kommenden Monat die gesamte Backup-Landschaft mitsamt einem bereits im Lager liegenden neuen Backup-Server auf SMB umzustellen. Jetzt mache ich halt mal Q&D NTFS aus dem Repository und nächsten Monat kommt alles auf Freigaben.
Machs doch gleich richtig per xfs auf immutable dann ist ruhe.
Unveränderliche Freigaben bietet auch die Syno an ... dazu brauch ich nicht mal xfs. Aber im Hinterkopf habe ich das.
Aber ich erstelle eh noch nen Medienumbruch auf Tape der ausgelagert wird.
Aber ich erstelle eh noch nen Medienumbruch auf Tape der ausgelagert wird.
1
Ich bin nicht auf dem aktuellen Stand was veeam immutable Backups angeht aber das kauf ich dir nicht ab.
Hast du evtl. Infos dazu?
Hast du evtl. Infos dazu?
Moin,
Ich klinke mich mal ein, aber eher aus Neugier denn als Helfender:
Wir selbst nutzen Veeam und haben unser Backup-Repo an einem IBM-SAN hängen. Die gemountete LUN ist ebenfalls mit ReFS formatiert.
Jetzt lese ich hier im Verlauf raus, dass ihr alle davon abratet. Ihr alle habt eure Targets aber per iSCSI angebunden - und das haben wir anders: FC und dazu dann die MPIO aktiviert. Und der VEEAM-Server ist auch in der FC-Zone eingebunden, in der die ESXi-LUNs liegen, damit Veeam direkten Zugriff hat. Wichtig aber: die LUNs müssen offline bleiben.
Wir sind hier eure Erfahrungen, speziell ReFS auf einer per FC eingebundenen LUN?
Ich klinke mich mal ein, aber eher aus Neugier denn als Helfender:
Wir selbst nutzen Veeam und haben unser Backup-Repo an einem IBM-SAN hängen. Die gemountete LUN ist ebenfalls mit ReFS formatiert.
Jetzt lese ich hier im Verlauf raus, dass ihr alle davon abratet. Ihr alle habt eure Targets aber per iSCSI angebunden - und das haben wir anders: FC und dazu dann die MPIO aktiviert. Und der VEEAM-Server ist auch in der FC-Zone eingebunden, in der die ESXi-LUNs liegen, damit Veeam direkten Zugriff hat. Wichtig aber: die LUNs müssen offline bleiben.
Wir sind hier eure Erfahrungen, speziell ReFS auf einer per FC eingebundenen LUN?
Moin @pcpanik,
wie ich schon weiter oben geschrieben habe, für das Windows und somit auch Veeam, ist eine lokal per SATA/SAS/PCIe angeschlossener Datenträger +- dasselbe wie eine von einem SAN oder NAS per SAS/FC/iSCSI beleitgestelte Block-LUN, da beides Basisdatenträger.
Siehe folgende Beispiel.
Der Erste Datenträger ist eine lokale PCIe SSD und die anderen beiden, werden von einem SAN bereitgestellt,
für Windows ist datenträgertyptechnisch jedoch beides dasselbe. 🙃
Und ja, theoretisch kann man dennoch ermitteln, ob der entsprechende Datenträger wirklich ein lokaler Datenträger ist oder von einem SAN kommt, dafür scheinen die entsprechenden Entwickler, jedoch viel zu faul zu sein. 😔
Na ja, mit dem abraten hat @user217 so nicht ganz unrecht, den es existiert tatsächlich ein mittlerweile über 5 Jahre alter Artikel von Veeam, in dem das wirklich so drin steht und zwar der folgende.
https://www.veeam.com/kb2792
Und das ReFS gleich so viele "Alergieen" hat, habe ich selbst übrigens nicht gewusst.
Angesichts dieses Artikels der ja von Veeam selber kommt, frage ich mich ernsthaft, was sich dieser Hersteller dabei denkt, bei der Einrichtung eines neuen Repos, pauschal auf die Nutzung von ReFS zu verweisen, ohne jedoch den jeweiligen Datenträger anständig zu prüfen und wenigstens eine Warnmeldung anzuzeigen, dass ReFS nur unter bestimmten Bedingungen benutzt werden darf. 😔
Mir auch, daher verwenden wir bei unseren Projekten auch nach wie vor SAN's und kein meiner Ansicht nach Murks-Storage wie S2D. 🙃
👍, damit haben wir bei Veeam, vor allem die letzten Jahre, die bessere Erfahrung gemacht.
Kannst ja nach der Umstellung hier auch mal berichten wie es dann bei dir mit SMB im Vergleich zu iSCSI läuft. 😉
Na ja, wenn ein Angreifer Zugang zum Veeam-Server bekommt, dann sind die Backupdaten die sich auf einem ständig online befindlichen SAN oder auch NAS befinden, meiner Ansicht nach ähnlich gefährdet, weil der Veeam Server schlichtweg meistens ständig auf beides zugreifen kann. Daher packen wir einen Backupserver auch niemals mit in die Produktive-Domäne mit rein, sondern isolieren diesen in einem eigenständigen Management/Backup Netz, genau so wie auch das entsprechende Backup SAN/NAS. Plus ausserhaus Backups, die momentan bei vielen Kunden z.B. auf RDX geschrieben und nach der Erstellung auch gleich ausgespuckt werden.
Ich drücke die Daumen.
Gruss Alex
Ich lass das mal so im Raum stehen, was deren Software einem Admin dazu sagt, wenn man es einrichtet.
Die scheint ja nicht zu prüfen, ob es sich um ein per iSCSI eingebundes Volume handelt.
Die scheint ja nicht zu prüfen, ob es sich um ein per iSCSI eingebundes Volume handelt.
wie ich schon weiter oben geschrieben habe, für das Windows und somit auch Veeam, ist eine lokal per SATA/SAS/PCIe angeschlossener Datenträger +- dasselbe wie eine von einem SAN oder NAS per SAS/FC/iSCSI beleitgestelte Block-LUN, da beides Basisdatenträger.
Siehe folgende Beispiel.
für Windows ist datenträgertyptechnisch jedoch beides dasselbe. 🙃
Und ja, theoretisch kann man dennoch ermitteln, ob der entsprechende Datenträger wirklich ein lokaler Datenträger ist oder von einem SAN kommt, dafür scheinen die entsprechenden Entwickler, jedoch viel zu faul zu sein. 😔
Von "davon wird abgeraten" erkennt man in dem Moment mal nichts.
Na ja, mit dem abraten hat @user217 so nicht ganz unrecht, den es existiert tatsächlich ein mittlerweile über 5 Jahre alter Artikel von Veeam, in dem das wirklich so drin steht und zwar der folgende.
https://www.veeam.com/kb2792
Und das ReFS gleich so viele "Alergieen" hat, habe ich selbst übrigens nicht gewusst.
Angesichts dieses Artikels der ja von Veeam selber kommt, frage ich mich ernsthaft, was sich dieser Hersteller dabei denkt, bei der Einrichtung eines neuen Repos, pauschal auf die Nutzung von ReFS zu verweisen, ohne jedoch den jeweiligen Datenträger anständig zu prüfen und wenigstens eine Warnmeldung anzuzeigen, dass ReFS nur unter bestimmten Bedingungen benutzt werden darf. 😔
Was den Storage angeht, da führen viele Wege nach Rom.
Mir ist es lieber, der ist vom BS separiert.
Mir ist es lieber, der ist vom BS separiert.
Mir auch, daher verwenden wir bei unseren Projekten auch nach wie vor SAN's und kein meiner Ansicht nach Murks-Storage wie S2D. 🙃
Und ich werde zukünftig wieder auf Freigaben setzen.
👍, damit haben wir bei Veeam, vor allem die letzten Jahre, die bessere Erfahrung gemacht.
Kannst ja nach der Umstellung hier auch mal berichten wie es dann bei dir mit SMB im Vergleich zu iSCSI läuft. 😉
Lokaler und per iSCSI eingebundener Storage lässt sich meiner Auffasung nach zudem zu leicht kompromittieren.
Na ja, wenn ein Angreifer Zugang zum Veeam-Server bekommt, dann sind die Backupdaten die sich auf einem ständig online befindlichen SAN oder auch NAS befinden, meiner Ansicht nach ähnlich gefährdet, weil der Veeam Server schlichtweg meistens ständig auf beides zugreifen kann. Daher packen wir einen Backupserver auch niemals mit in die Produktive-Domäne mit rein, sondern isolieren diesen in einem eigenständigen Management/Backup Netz, genau so wie auch das entsprechende Backup SAN/NAS. Plus ausserhaus Backups, die momentan bei vielen Kunden z.B. auf RDX geschrieben und nach der Erstellung auch gleich ausgespuckt werden.
So, die Copy Jobs legen bereits neue Full Backups an.... jetzt heißt es abwarten.
Ich drücke die Daumen.
Gruss Alex
Moin @user217,
ganz sicher nicht, den XFS Immuability ist nur ein eine Art "pseudo WORM", da der root User dennoch jederzeit alle Daten löschen kann!
Gruss Alex
Machs doch gleich richtig per xfs auf immutable dann ist ruhe.
ganz sicher nicht, den XFS Immuability ist nur ein eine Art "pseudo WORM", da der root User dennoch jederzeit alle Daten löschen kann!
Gruss Alex
Moin @em-pie,
ob per iSCSI oder FC macht in dem Fall keinen grossen Unterschied, da du auch bei FC Verbindungsprobleme haben kannst, jedoch sind diese bei FC deutlich seltener als bei iSCSI. Dennoch würde ich aus Erfahrung behaupten, dass du trotz deiner Umgebung, demselben Risiko ausgesetzt bist, aber eben mit einer geringeren Eintrittswahrscheinlichkeit. 😔
Um die Wahrscheinlichkeit eines Defekts eines ReFS-Volumes zu minimieren, solltest du bei Veeam das "Fast Cloning" deaktivieren. 😉
https://www.veeam.com/kb4381
Übrigens, der Lösungsvorschlag Nr. 1 dieses Artikels ist ein Fileshare, sprich ein NAS als Repo zu benutzen. 🙃
Was für ein Wirrwarr seitens des Herstellers und das bei einem derart wichtigen Thema wie Backups. 😔
Aber ja, spätestens seit der Übernahme von Veeam durch "Insight Partners" ist Veeam für mich nicht mehr wirklich ein Technologieunternehmen, da Venture-Capital-Unternehmen primär nicht wirklich daran interessiert sind eine Technologie zu fördern, sondern eher daran, das bisheriges Kapital so gut es geht noch weiter zu erhöhen. 🤮🤮🤮
Sprich, Veeam mutiert meiner Ansicht nach so langsam zum selben Technologie-Saftladen wie auch Broadcom & Co.
Gruss Alex
Jetzt lese ich hier im Verlauf raus, dass ihr alle davon abratet. Ihr alle habt eure Targets aber per iSCSI angebunden - und das haben wir anders: FC und dazu dann die MPIO aktiviert. Und der VEEAM-Server ist auch in der FC-Zone eingebunden, in der die ESXi-LUNs liegen, damit Veeam direkten Zugriff hat. Wichtig aber: die LUNs müssen offline bleiben.
Wir sind hier eure Erfahrungen, speziell ReFS auf einer per FC eingebundenen LUN?
Wir sind hier eure Erfahrungen, speziell ReFS auf einer per FC eingebundenen LUN?
ob per iSCSI oder FC macht in dem Fall keinen grossen Unterschied, da du auch bei FC Verbindungsprobleme haben kannst, jedoch sind diese bei FC deutlich seltener als bei iSCSI. Dennoch würde ich aus Erfahrung behaupten, dass du trotz deiner Umgebung, demselben Risiko ausgesetzt bist, aber eben mit einer geringeren Eintrittswahrscheinlichkeit. 😔
Um die Wahrscheinlichkeit eines Defekts eines ReFS-Volumes zu minimieren, solltest du bei Veeam das "Fast Cloning" deaktivieren. 😉
https://www.veeam.com/kb4381
Übrigens, der Lösungsvorschlag Nr. 1 dieses Artikels ist ein Fileshare, sprich ein NAS als Repo zu benutzen. 🙃
Was für ein Wirrwarr seitens des Herstellers und das bei einem derart wichtigen Thema wie Backups. 😔
Aber ja, spätestens seit der Übernahme von Veeam durch "Insight Partners" ist Veeam für mich nicht mehr wirklich ein Technologieunternehmen, da Venture-Capital-Unternehmen primär nicht wirklich daran interessiert sind eine Technologie zu fördern, sondern eher daran, das bisheriges Kapital so gut es geht noch weiter zu erhöhen. 🤮🤮🤮
Sprich, Veeam mutiert meiner Ansicht nach so langsam zum selben Technologie-Saftladen wie auch Broadcom & Co.
Gruss Alex
Na ja, wenn ein Angreifer Zugang zum Veeam-Server bekommt, dann sind die Backupdaten die sich auf einem ständig online befindlichen SAN oder auch NAS befinden, meiner Ansicht nach ähnlich gefährdet, weil der Veeam Server schlichtweg meistens ständig auf beides zugreifen kann.
Stimmt nicht ganz. Hast du dir
Das Immutable Konzept schon mal richtig angeschaut mit den Immutable flags? Das ist ja keine Erfindung von Veeam. Wenn es sich um ein immutable Storage handelt wird es schwierig mit löschen der Daten, dabei ist es egal, ob ich Vollzugriff auf den Veeamserver habe.
Ich kann dir gern Screenshot zeigen, wie es eben nicht funktioniert unter die Veeam Konsole zu löschen.
Das ganz wird aber eben durch den Reposerver mit XFS geregelt und wenn man diesen entsprechend härtet und sogar SSH deaktiviert (Veeam brauch zum Transport der Backups kein SSH) wirds dann schon schwieriger.
Daher auch klar die Empfehlung und meine Erfahrungen… physischer Repo Server mit 24/36 Bay hat hier bedeutend weniger Angriffsfläche als ein Syno oder QNAP.
Unabhängig davon gehört natürlich, wie du bereits richtig erwähnt hast, das Backup- und Management Netzwerk klar separiert
2Zitat von @MysticFoxDE:
Moin @pcpanik,
wie ich schon weiter oben geschrieben habe, für das Windows und somit auch Veeam, ist eine lokal per SATA/SAS/PCIe angeschlossener Datenträger +- dasselbe wie eine von einem SAN oder NAS per SAS/FC/iSCSI beleitgestelte Block-LUN, da beides Basisdatenträger.
Siehe folgende Beispiel.
Der Erste Datenträger ist eine lokale PCIe SSD und die anderen beiden, werden von einem SAN bereitgestellt,
für Windows ist datenträgertyptechnisch jedoch beides dasselbe. 🙃
Und ja, theoretisch kann man dennoch ermitteln, ob der entsprechende Datenträger wirklich ein lokaler Datenträger ist oder von einem SAN kommt, dafür scheinen die entsprechenden Entwickler, jedoch viel zu faul zu sein. 😔
Na ja, mit dem abraten hat @user217 so nicht ganz unrecht, den es existiert tatsächlich ein mittlerweile über 5 Jahre alter Artikel von Veeam, in dem das wirklich so drin steht und zwar der folgende.
https://www.veeam.com/kb2792
Und das ReFS gleich so viele "Alergieen" hat, habe ich selbst übrigens nicht gewusst.
Angesichts dieses Artikels der ja von Veeam selber kommt, frage ich mich ernsthaft, was sich dieser Hersteller dabei denkt, bei der Einrichtung eines neuen Repos, pauschal auf die Nutzung von ReFS zu verweisen, ohne jedoch den jeweiligen Datenträger anständig zu prüfen und wenigstens eine Warnmeldung anzuzeigen, dass ReFS nur unter bestimmten Bedingungen benutzt werden darf. 😔
Mir auch, daher verwenden wir bei unseren Projekten auch nach wie vor SAN's und kein meiner Ansicht nach Murks-Storage wie S2D. 🙃
👍, damit haben wir bei Veeam, vor allem die letzten Jahre, die bessere Erfahrung gemacht.
Kannst ja nach der Umstellung hier auch mal berichten wie es dann bei dir mit SMB im Vergleich zu iSCSI läuft. 😉
Na ja, wenn ein Angreifer Zugang zum Veeam-Server bekommt, dann sind die Backupdaten die sich auf einem ständig online befindlichen SAN oder auch NAS befinden, meiner Ansicht nach ähnlich gefährdet, weil der Veeam Server schlichtweg meistens ständig auf beides zugreifen kann. Daher packen wir einen Backupserver auch niemals mit in die Produktive-Domäne mit rein, sondern isolieren diesen in einem eigenständigen Management/Backup Netz, genau so wie auch das entsprechende Backup SAN/NAS. Plus ausserhaus Backups, die momentan bei vielen Kunden z.B. auf RDX geschrieben und nach der Erstellung auch gleich ausgespuckt werden.
Ich drücke die Daumen.
Gruss Alex
Moin @pcpanik,
Ich lass das mal so im Raum stehen, was deren Software einem Admin dazu sagt, wenn man es einrichtet.
Die scheint ja nicht zu prüfen, ob es sich um ein per iSCSI eingebundes Volume handelt.
Die scheint ja nicht zu prüfen, ob es sich um ein per iSCSI eingebundes Volume handelt.
wie ich schon weiter oben geschrieben habe, für das Windows und somit auch Veeam, ist eine lokal per SATA/SAS/PCIe angeschlossener Datenträger +- dasselbe wie eine von einem SAN oder NAS per SAS/FC/iSCSI beleitgestelte Block-LUN, da beides Basisdatenträger.
Siehe folgende Beispiel.
für Windows ist datenträgertyptechnisch jedoch beides dasselbe. 🙃
Und ja, theoretisch kann man dennoch ermitteln, ob der entsprechende Datenträger wirklich ein lokaler Datenträger ist oder von einem SAN kommt, dafür scheinen die entsprechenden Entwickler, jedoch viel zu faul zu sein. 😔
Von "davon wird abgeraten" erkennt man in dem Moment mal nichts.
Na ja, mit dem abraten hat @user217 so nicht ganz unrecht, den es existiert tatsächlich ein mittlerweile über 5 Jahre alter Artikel von Veeam, in dem das wirklich so drin steht und zwar der folgende.
https://www.veeam.com/kb2792
Und das ReFS gleich so viele "Alergieen" hat, habe ich selbst übrigens nicht gewusst.
Angesichts dieses Artikels der ja von Veeam selber kommt, frage ich mich ernsthaft, was sich dieser Hersteller dabei denkt, bei der Einrichtung eines neuen Repos, pauschal auf die Nutzung von ReFS zu verweisen, ohne jedoch den jeweiligen Datenträger anständig zu prüfen und wenigstens eine Warnmeldung anzuzeigen, dass ReFS nur unter bestimmten Bedingungen benutzt werden darf. 😔
Was den Storage angeht, da führen viele Wege nach Rom.
Mir ist es lieber, der ist vom BS separiert.
Mir ist es lieber, der ist vom BS separiert.
Mir auch, daher verwenden wir bei unseren Projekten auch nach wie vor SAN's und kein meiner Ansicht nach Murks-Storage wie S2D. 🙃
Und ich werde zukünftig wieder auf Freigaben setzen.
👍, damit haben wir bei Veeam, vor allem die letzten Jahre, die bessere Erfahrung gemacht.
Kannst ja nach der Umstellung hier auch mal berichten wie es dann bei dir mit SMB im Vergleich zu iSCSI läuft. 😉
Lokaler und per iSCSI eingebundener Storage lässt sich meiner Auffasung nach zudem zu leicht kompromittieren.
Na ja, wenn ein Angreifer Zugang zum Veeam-Server bekommt, dann sind die Backupdaten die sich auf einem ständig online befindlichen SAN oder auch NAS befinden, meiner Ansicht nach ähnlich gefährdet, weil der Veeam Server schlichtweg meistens ständig auf beides zugreifen kann. Daher packen wir einen Backupserver auch niemals mit in die Produktive-Domäne mit rein, sondern isolieren diesen in einem eigenständigen Management/Backup Netz, genau so wie auch das entsprechende Backup SAN/NAS. Plus ausserhaus Backups, die momentan bei vielen Kunden z.B. auf RDX geschrieben und nach der Erstellung auch gleich ausgespuckt werden.
So, die Copy Jobs legen bereits neue Full Backups an.... jetzt heißt es abwarten.
Ich drücke die Daumen.
Gruss Alex
Wenn du den Repo Server entsprechend härtest kommst du aber nicht drauf.
- ssh deaktivieren und nur Zugriff via lokaler Bildschirm Konsole erlauben.
- falls ssh zwingend notwendig ist, dass natürlich nur mit MFA
Moin @tech-flare,
Ja, aber ehrlich gesagt nur oberflächlich. Das mit den Flags habe ich jedoch durchaus wahrgenommen aber auch die Hinweise, dass die Konfiguration absolut korrekt erfolgen muss, damit der entsprechende Storage dann auch wirklich "Immutable" ist.
Auch das ist mir durchaus bewusst.
Ja, aber nur wenn es wie du es auch schon selber geschrieben hast, korrekt gehärtet ist.
Ich glaube dir schon, dass du das alles richtig einrichten kannst.
Ob das jedoch alle anderen auch genau so hinbekommen, wage ich jedoch ganz arg zu bezweifeln, da viele ITler nicht wirklich irgendwelche Anleitungen lesen, sondern eher weiter weiter und fertig klicken.
Die QNAP's und Synos kann man ja auch härten oder man nimmt einfach ein Enterprise-NAS wie z.B. ...
https://www.infortrend.com/de/products/families/gs/3000
... und hat damit auch gleich eine HA Backup-Storage, was du so mit dem physischer Repo Server, nicht ganz einfach hinbekommst.
Und ja, auf den Infortrend-SAN's kannst du auch mit Veeam Immutable Backups ablegen, da sie natürlich auch Amazon S3 kompatibel sind und WORM können die zudem auch noch bereitstellen. 😁
Verflixt, jetzt hast du mich tatsächlich etwas scharf auf die Immutable Backups gemacht. 🤪
Mal sehen, vielleicht probiere ich das bei der nächsten Backup-SAN Umstellung mal aus.
Gruss Alex
Stimmt nicht ganz. Hast du dir das Immutable Konzept schon mal richtig angeschaut mit den Immutable flags?
Ja, aber ehrlich gesagt nur oberflächlich. Das mit den Flags habe ich jedoch durchaus wahrgenommen aber auch die Hinweise, dass die Konfiguration absolut korrekt erfolgen muss, damit der entsprechende Storage dann auch wirklich "Immutable" ist.
Das ist ja keine Erfindung von Veeam.
Auch das ist mir durchaus bewusst.
Wenn es sich um ein immutable Storage handelt wird es schwierig mit löschen der Daten, dabei ist es egal, ob ich Vollzugriff auf den Veeamserver habe.
Ja, aber nur wenn es wie du es auch schon selber geschrieben hast, korrekt gehärtet ist.
Ich kann dir gern Screenshot zeigen, wie es eben nicht funktioniert unter die Veeam Konsole zu löschen.
Ich glaube dir schon, dass du das alles richtig einrichten kannst.
Ob das jedoch alle anderen auch genau so hinbekommen, wage ich jedoch ganz arg zu bezweifeln, da viele ITler nicht wirklich irgendwelche Anleitungen lesen, sondern eher weiter weiter und fertig klicken.
Das ganz wird aber eben durch den Reposerver mit XFS geregelt und wenn man diesen entsprechend härtet und sogar SSH deaktiviert (Veeam brauch zum Transport der Backups kein SSH) wirds dann schon schwieriger.
Daher auch klar die Empfehlung und meine Erfahrungen… physischer Repo Server mit 24/36 Bay hat hier bedeutend weniger Angriffsfläche als ein Syno oder QNAP.
Daher auch klar die Empfehlung und meine Erfahrungen… physischer Repo Server mit 24/36 Bay hat hier bedeutend weniger Angriffsfläche als ein Syno oder QNAP.
Die QNAP's und Synos kann man ja auch härten oder man nimmt einfach ein Enterprise-NAS wie z.B. ...
https://www.infortrend.com/de/products/families/gs/3000
... und hat damit auch gleich eine HA Backup-Storage, was du so mit dem physischer Repo Server, nicht ganz einfach hinbekommst.
Und ja, auf den Infortrend-SAN's kannst du auch mit Veeam Immutable Backups ablegen, da sie natürlich auch Amazon S3 kompatibel sind und WORM können die zudem auch noch bereitstellen. 😁
Verflixt, jetzt hast du mich tatsächlich etwas scharf auf die Immutable Backups gemacht. 🤪
Mal sehen, vielleicht probiere ich das bei der nächsten Backup-SAN Umstellung mal aus.
Gruss Alex
ReFS in dieser Konstellation, also ohne Storage Spaces und ohne Integrity Streams, löst oder verursacht keine grundlegenden Probleme im Vergleich zu NTFS.
Die konzeptionelle Zielsetzung von ReFS ist aber, unter keinen Umständen unerkannt falsche Daten auszuliefern. Entsprechend hast du in Bezug auf die Dateisystemintegrität unter Fehlerbedingungen eine Alles-oder-nichts-Situation.
Die Frage ist daher in Abhängigkeit zur Fehlerhäufigkeit: Möchte ich die funktionalen Vorteile von ReFS für Veeam-Repos mit einem Neubeginn auf einem neuen Volume im (vergleichsweise niedrigschwellig detektierten) Fehlerfall erkaufen oder akzeptiere ich die Nachteile von NTFS für den Workload, weil der Prozess "chkdsk mit anschließender Backup-Verifikation" praktikabler ist - selbst wenn ich ihn ggf. präventiv, mangels klarer Indikation, durchführen muss.
Nicht zwingend, aber in den meisten praktischen Fällen halte ich in dem Zusammenhang einen iSCSI-Stack für zu fragil, um ReFS zu hosten. Ein FC-SAN ist vertretbar, auch weil die Umgebungen höherwertig sein dürften.
Die zentrale Empfehlung von Veeam für Block- bzw. Tier-1-Repos lautet: Generische Server-Hardware mit DAS - beim Einsatz von Windows mit ReFS formatiert. Da kann ich jedenfalls nicht ReFS rauspicken, über iSCSI mounten und behaupten, das wäre quasi Best Practice. Diverse Alternativen werden unterstützt, aber dann müssen die technischen Implikationen aller Folgeabweichungen bewertet und abgewogen werden. Wenn das getan würde, würde meines Erachtens in den meisten Fällen auch von den Alternativen abgerückt, anstatt eben beispielsweise 80k unter falschen Erwartungen zu investieren und die Lösung dann mit NTFS "passend zu machen".
Zitat von @user217:
Ich bin nicht auf dem aktuellen Stand was veeam immutable Backups angeht aber das kauf ich dir nicht ab.
Hast du evtl. Infos dazu?
Ich bin nicht auf dem aktuellen Stand was veeam immutable Backups angeht aber das kauf ich dir nicht ab.
Hast du evtl. Infos dazu?
Warum nicht? Ich sprach von unveränderlichen Freigaben. Hier Infos: https://blog.synology.com/ger/anleitung-was-ist-worm-schreib-und-loeschs ...
Die Backup Synos stehen im gesonderten Backup-Netz, machen 2FA, haben keine AD Anbindung, SSH und Co ist aus. Sehe da nun wirklich kein Problem die als Repos zu benutzen, insbesondere da wir das jetzt seit vielen Jahren so machen. Das Windows sein ReFS schrottet ist ja kein Fehler einer iSCSI LUN.
Meine Copys waren nach 3 Tagen wieder von Veeam angelegt. Ärgerlich, aber immerhin wieder ok. Jetzt heißt es bald auf einen neuen Backup-Server umziehen und alles auf Freigaben umstellen.
