SMB Limit Dateigröße - Backup schlägt immer fehl

    Hallo und Guten Morgen


    Ich versuche gerade Backups von VMs via Altaro und Veeam zum machen. Die große VM mit 23TB scheitert immer bei genau 16TB - gibt es da ein Limit bei Qnap bzw Transfer über SMB was da immer "zumacht"?


    Die Backupprogramme sagen:

    Altaro sagt: Job failed - kann auf Datei xyz nicht zugreifen/schreiben

    Veeam sagt: Job failed - kein Platz auf Zieldatenträger


    Beides ist per se Quatsch, ich kann auf die Dateien lesend und schreiben zugreifen (gleicher SMB User auf gleicher Maschine) und es sind noch 16TB frei!?


    Verbindung ist SMB3 (alles andere ist deaktiviert), keine OPLocks


    HW:
    Qnap 453D mit 4x 12TB Toshiba Enterprise SATA HDDs, aktuelle FW 4.5.1.1540 (war mit der alten W aber auch das Problem)


    Hat da jemand Infos(Ideen warum das immer bei 16TB fehl schlägt, das ist so auffällig da muss ja irgendwas sein.


    Danke, grüße

    Zitat von Crazyhorse

    Was sagte denn der Support des Herstellers dazu?

    Also Altaro und Veeam sagen es liegt nicht am Backup-Program - Ursache ist beim NAS/Netzwerk zu suchen.
    Veeam Wiki sagt am NAS den Cache deaktivieren, hab ich gemacht, hilft aber nix....


    Das Netzwerk läuft 24/7 und ist ein Cisco 350 10GB 8 Port Switch, wenn da was defekt wäre würden das alle sofort merken.


    Mit dem Qnap habe ich letztes Jahr per iSCSI mehrfach über 30TB übertragen und darüber gearbeitet das ging problemlos.


    Somit wäre aus meiner Sicht die einzige Möglichkeit ein Problem mit dem SMB Protokoll - nur ich finde bisher keinen Hinweis darauf - Windows Log ist leer.

    Der freie Platz muss immer mindestens so groß sein wie die größte zu schreibende Datei.

    Zitat von dr_mike

    Der freie Platz muss immer mindestens so groß sein wie die größte zu schreibende Datei.

    Ok.


    Also so fängt das Backup an:

    NAS belegt 0TB (also alles leer), frei 32TB.


    Es wird vom Backup Tool 1 Datei geschrieben in der die VM komplett gespeichert wird - die VM hat eine Gesamtgröße von 23TB.

    Wenn ich den Backup Prozess beginne ist also genug Platz vorhanden.


    Die Meldung von Veeam kommt bei geschriebenen 16TB, bei Altaro kann ich das nicht direkt sehen, von der zeit her, beide kopieren gleich schnell, ist es auch so um die 16TB.

    Zitat von blub

    Hat da jemand Infos(Ideen warum das immer bei 16TB fehl schlägt, das ist so auffällig da muss ja irgendwas sein.


    Hast du das NAS "damals" neu aufgesetzt oder wurde es migriert ? Wenn ja von welchem NAS.

    Ja das Nas ist neu, die HDDs auch.


    dr_mike

    Ich schrieb dass noch 16TB frei sind nachdem das Backup bei 16TB übertragenen Daten abbricht - dachte dass damit klar wäre dass genug Platz vorhanden ist.

    Einmal editiert, zuletzt von blub ()

    Es gab früher einmal eine 16 TB Limite für Volumes. Das Erstellen darüber war nicht möglich. Gehe aber davon aus, dass Dein Volume schon die volle 32 TB hat.

    Problem dürfte sein, dass nicht all zu viele Benutzer mit so großen Dateien unterwegs sind. Gut möglich, dass hier ein Bug in der Firmware ist.


    Volume: Thick, thin oder static? Formatierung denke ich mal ext4, ansonsten wäre ja schon bei 2 TB Schluss.


    Die 23 TB, sind die nur von einer einzigen VM? Als Workaround wäre ansonsten das Aufteilen im mehrere Jobs. Mit welchem Programm von Veeam sicherst Du?

    Hi


    Volume type: thick volume

    Size: 32,37TB

    Dateisystem: müsste ext4 sein, finde aber gerade den Eintrag nicht

    Benutzer: Es ist nur ein nutzer überhaupt unterwegs


    Veeam: Aktuelle B&R Testversion 10.0.1


    Job:

    ja die 23TB sind eine einzige VM - alle VMs die kleiner sind kann ich problemlos auf diesem NAS oder woanders sichern, nur diese eine VM und die andere mit 20TB+ scheitern immer -

    Ich meinte den Hersteller des NAS, also QNAP.

    Sieht sehr nach Bug aus.


    Snapshots sind keine aktiv?

    Kannst mal auf dem NAS schauen wenn das BU läuft was hier auf dem Volume, Raid Pool, Speicherpool passiert.


    Im NAS Log müsste ja eine Meldung kommen wenn er dir wegen der Dateigröße abbricht.

    Die maximale Größe einer Datei hängt bei ext4 von der bei der Formatierung verwendeten Block-Größe ab. Mit 4 KiB können Dateien "nur" 16 TiB groß sein. Es gibt beim Formatieren sogar einen Assistenten dafür, der die jeweiligen Limits hinsichtlich Anzahl der Dateien, Größe usw. anzeigt. Also evtl. nochmal neu formatieren, wenn das NAS eh leer ist. Ansonsten kann man die aktuelle Konfiguration auch per ssh abfragen.


    Der Haken bei größeren Blöcken ist, dass für kleine Dateien mindestens ein Block reserviert wird, d.h. für viele kleine Dateien sind kleinere Blockgrößen effizienter vom Speicherverbrauch.


    Aber mal ehrlich, wer hat denn 23 TiB in einer einzigen Datei und sichert diese dann auch noch auf ein so kleines SMB-NAS? Wieviel Jahre soll denn das Backup laufen? Vielleicht solltet ihr euch mal ein sinnvolleres VM-Speicherkonzept überlegen, niemand braucht 23 TiB in einer einzigen VM.

    Ahhh.. das klingt plausibel. da habe ich beim erstellen natürlich nicht drauf geachtet.


    Das NAS ist nicht so klein und hat eine 10GB Karte, damit dauert das auch nicht ewig da die Schreibgeschwindigkeit konstant 320-350MB/S sind - das ist unser 2. Backup dieser VM das nur monatlich aktualisiert wird und dann off-site gelagert wird - da wir von der Telekom nur mit DSL 60/20 versogt werden ist dass der beste Kompromiss.


    zu VM:
    Wir betrieben eine VM für einen Server mit dem "wir unser Geld verdienen" - für den Bereich in dem wir uns bewegen sind 23TB noch klein da wir erst 2010 angefangen haben unsere Daten auf HDDs langzeit zu speichern - vorher sind wir nach 1 Jahr auf CD/DVD gewechselt - wir haben tausende CD/DVD seit 1998 :)

    sollen wir also alle 2TB neu neue VM oder VHDx aufmachen? - Aktuell reichen 2 TB nicht mal für ein Jahr....
    ...oder uns ein Arschteuers SAN hinstellen dass wir alleine aufgrund der geringen User-VM-Anzahl gar nicht brauchen?

    Das ist so schon ganz richtig und andere machen das teilweise noch ohne VM, wenn die dann mal mit 250Millionen Dateien den Server wechseln kopieren die Wochen bis Monate, wir sind damit in 13 Stunden fertig, das passt schon :)


    Zum Backup: De VM wird 1x Tag auf den 2. HyperV respiegelt/repliziert, wir können 1 Tag ohne weiteres "nachkopieren" vom den Datenerzeugern - das Backup über das wir hier reden ist daher so schon OK mit dem NAS



    Edit:

    OK, gerade nachgesehen - das Volume hat 64k Blöcke, also daran kann es nicht liegen.

    Einmal editiert, zuletzt von blub ()

    Ich konnte Andeutungen im Internet finden, dass es wohl im SMB/CIFS-Protokoll eine 16 TB Limite geben könnte, oder gegeben hat. Leider konnte ich da bis jetzt keine konkreteren Angaben finden. 16 TB ist auch heute nicht gerade die Standard-Filegröße. ;)


    Zu Versuchszwecken könnte aber auch NFS herhalten. Sollte es da funktionieren... aber NFSv4 verwenden, denn NFSv3 hat wohl auch eine Größenlimitierung.

    OK, danke. Ich habe zu SMB/CIFS bisher nicht als Limit gefunden.


    Weder Altaro noch Veeam weisen in Ihren KB Artikeln auf ein Limit bei SMB/Nas hin.

    Veeam hat eine Einstellung für VHDX über 100TB und empfiehlt hier local drives..


    Ich habe jetzt einfach mal iscsi aufgesetzt und versuche es jetzt nochmal mit beiden Programmen.

    Mal sehen ob es klappt, ETA morgen Vormittag...

    Ich sage ja nicht, dass 23 TB unrealistisch sind, aber warum müssen die in EINEM Container sein. Solche Monster-Monolithe machen nur unnötigen Ärger.

    Zitat von blub

    sollen wir also alle 2TB neu neue VM oder VHDx aufmachen? - Aktuell reichen 2 TB nicht mal für ein Jahr....

    Naja, vielleicht nicht alle 2TB, aber vielleicht alle 4, 8 oder 10TB einen neuen Container (halt irgendwas Gängiges, 16TB ist halt wieder so 'ne magische Grenze). Damit skalieren auch die Backup-Zeiten besser, da ihr ja wohl kaum immer alle Daten verändert, sondern wahrscheinlich nur die neuesten. Evtl. lassen sich alte Daten dann sogar einfach archivieren, weil man sie aktiv gar nicht benötigt (z.B. die von 1998 ;) ). Aber das müsst ihr wissen :cup:

    Zitat von Mavalok2

    Zu Versuchszwecken könnte aber auch NFS herhalten. Sollte es da funktionieren... aber NFSv4 verwenden, denn NFSv3 hat wohl auch eine Größenlimitierung.

    mhh OK, aber das wäre über Windows ja wieder ein Akt wenn ich das mit Altaro oder Veeam zum laufen bringen möchte



    Zitat von warpcam

    Evtl. lassen sich alte Daten dann sogar einfach archivieren, weil man sie aktiv gar nicht benötigt (z.B. die von 1998 ;) ). Aber das müsst ihr wissen

    Ja das ist per se nicht ganz verkehrt. Zumindest kann man langsam alte Daten zb auf HDDs ablegen, aktuell ist alles auf SSDs - dann hätte ich zwar ne 2. VHDX für die VM aber Veeam und Altaro würden das Backup, wenn ich mir aktuell den Backup-Ordner ansehe, dennoch eine datei schreiben die dann eben wieder 23TB hat - bringt dann glaube ich nicht viel...

    Zitat von blub

    mhh OK, aber das wäre über Windows ja wieder ein Akt wenn ich das mit Altaro oder Veeam zum laufen bringen möchte

    Nö, wieso denn? Windows Feature, Haken rein. Wobei ich zugeben muss, unter Windows Server habe ich es weder versucht, noch weiß ich jetzt, ob es das wie bei Win10 auch gibt. Und ja, hmm, mit Veeam NFS? Auch nicht ausprobiert, wenn überhaupt.

    Netzwerk – NFS Teil 2: Die alternative zur Microsoft-Netzwerk-Freigabe (SMB / Samba) – Windows-Clients

    Zitat von blub

    dennoch eine datei schreiben die dann eben wieder 23TB hat - bringt dann glaube ich nicht viel...

    Jep. Veeam sichert - standardmäßig zumindest - den ganzen Server mit allen Festplatten mit. Habe nie versucht das separieren zu wollen. Da wäre die Überlegung eines getrennten Archiv-Server mit nicht mehr so oft gebrauchten Daten eher eine Überlegung. Archivierte Daten müssen - wenn überhaupt - nicht mehr so oft gesichert werden. Wir haben in der Firma einen solchen Archiv-Server. Dessen Daten sind schreibgeschützt, sprich der normale Benutzer hat einfach keine Berechtigungen zur Veränderung. Lesen geht aber wohl. Die Daten sind zusätzlich auf mehreren Bändern gesichert und werden so alle 1-2 Jahre nachgeführt, sprich alte Daten wieder archiviert, wieder auf die Bänder geschupst und vom aktiven Daten-Server gelöscht. Archivierte Daten sind bei uns abgeschlossene Projekte, die meist schon 1-2 Jahre abgeschlossen sind. Könnte ja noch was... ;)

    Hi


    Also mir iscsi läuft es beim 1. Mal durch. Werde dann mal qnap anhauen was da los ist, sollte ja bei ext4 nicht passieren....



    Wir müssen die Daten etwas länger vorhalten, so ca 30 😭