Probleme mit Backup iSCSI LUN und Thin Provisioning

[tschoening]

Hallo zusammen,

wir haben eine DS 1512+, die eine iSCSI LUN mit 2 TB und als Thin Provisioning markiert zur Verfügung stellt. Im Dateisystem des NAS besteht die LUN aus zwei Dateien mit zusammen ca. 200 GB, also noch weit weg von der Grenze, innerhalb der LUN sind auch nur ca. 80 GB an Daten gespeichert. Diese LUN wurde von einem Server genutzt und sollte dann wegen Änderungen an der Infrastruktur auf einen anderen umgezogen werden, was auch alles problemlos geklappt hat. Bei diesem Prozess haben wir den Namen der LUN auf dem NAS in den entsprechenden Dialogen zur Bearbeitung auch geändert. Jetzt das Problem:

Diese LUN wurde per Sicherungsauftrag lokal in einen bestimmten Ordner gesichert und die Einstellungen für diesen Auftrag haben wir ebenfalls geändert, so dass das lokale Sicherungsziel, der Name des Auftrags usw. dem neuen Namen der LUN entspricht. Seitdem klappt die Sicherung aber leider nicht mehr, stattdessen bekommen wir folgende Fehlermeldung:

Local Backup failed to backup task [lxp-Postgres]. (Der verbrauchte Speicherplatz hat den Grenzwert des Zielservers erreicht.)

Ich habe den Sicherungsauftrag dann irgendwann einfach gelöscht und komplett neu angelegt. Beim Abschluss des Prozesses kommt dann folgende Meldung:

Auf dem Volume ist nicht genügend freier Speicherplatz vorhanden.

Das in der Meldung angesprochene Volume ist etwas über 2,5 TB groß und beinhaltet alle unsere Daten und einige interne Datensicherungen. Entscheidend ist, dass in diesem Volume noch ca. 850 GB frei sind, die LUN also theoretisch locker zusätzlich rein passt.

Kann es sein, dass diese Meldung kommt, weil die 2 TB maximale Größe der LUN als zu reservierender Speicher beim Backup gezählt werden?

Die LUN wurde ursprünglich früher mit dem ersten Sicherungsauftrag zu einem Zeitpunkt angelegt, als das interne Volume noch nicht so gefüllt war, sondern tatsächlich noch die 2 TB, die die LUN maximal brauchen darf, frei waren. Irgendwie beißt sich der Verdacht aber mit dem Feature Thin Provisioning, weil es sinnfrei erscheint, die maximale Größe heran zu ziehen, wenn die aktuelle nur 1/10 davon beträgt. Die LUN selbst wird ja auch nicht mit 2 TB im Dateisystem vorgehalten, sondern wächst einfach.

Falls ich falsch liege, was könnte sonst der Grund für die Fehlermeldungen bei der Sicherung sein? Wenn ich richtig liege, wie kann ich dieses Problem beheben? Ich will meine LUN auf das interne Volume sichern und genug Speicherplatz steht ja derzeit noch zur Verfügung. In den Anleitungen von Synology habe ich leider keine Aussage zu dieser Problematik gefunden.

Danke für eure Hilfe!

 

[tschoening]

Ich kann meine eigene Frage beantworten: Beim erstmaligen Backup will das NAS 4 GB große sparsed Dateien in der Gesamtgröße der zu sichernden Datenmenge anlegen, also tatsächlich 2 TB im konkreten Fall und benötigt auch dann, wenn es sich um sparsed Dateien handelt, den freien Speicherplatz, um diese Dateien anlegen zu können. Nach deren Erstellung belegen die keine 2 TB, sondern nur noch die Datenmenge, die tatsächlich bei der Sicherung anfällt, so dass man auch mit weniger freiem Speicher langfristig weiter sichern kann. Der Knackpunkt ist also tatsächlich, dass beim ersten Mal die sparsed Containerdateien für die Sicherung angelegt werden und dafür muss anscheinend der maximal benötigte Sicherungsspeicher zur Verfügung stehen. Bissel blöde implementiert irgendwie...

 

[BSFD]

Meine Meinung:
Das ist ein Grund warum ich iSCSI nicht mag und eher auf NFS setze. Man verbraucht eine unnötige Menge an Speicherplatz. Ich bin mir auch recht sicher, dass BTRFS nicht das Problem ist. Nur mal eine Zahl aus einer nicht Synology Umgebung die dies deutlich macht. BTRFS, ZFS und WAFL nutzen alle CopyOnWrite kurz COW, sind daher recht ähnlich aufgebaut. Wir haben aktuell 250 unterschiedliche Windows Server keine Clones, die wir auf einem ZFS Speicher mit LZ4 Kompression in 5TB betreiben. Die kleinste Maschine hat 8GB netto Speicherplatz und die größte aus dem Pool 634GB netto. Die größten 12 Maschinen belegen alleine schon etwa 2TB in VMware VMDK Dateien. Mir ist jetzt leider nicht bekannt, welche Daten in Ihrer LUN abgelegt sind, aber die Platzverschwendung mit iSCSI bleibt. Bei Datenbanken dürfte die Einsparung noch größer sein.