Projektsicherung mit VHD Containern?

[sikarr]

Moin,

wir sind in der Firma an einem Punkt angekommen wo das Datei Handling zunehmend schwieriger wird.
Ich arbeite in einer Digitalisierung, wir erzeugen also ziemlich viele und oft auch noch große Dateien. Problem ist hier eher die Menge und nicht die Größe.

Unsere Backupstrategie ansich funktioniert super, tägliche Sicherung, Bandsicherung etc.

Wir haben aber das Problem das uns die Arbeitslaufwerke auf den Servern volllaufen. Endlos den Speicher erhöhen ist auch keine Lösung da der Platz ja nur Temporär gebraucht wird, Sind wir dazu übergegangen abgeschlossene Projekte oder Teile davon ersteinmal temporär zwischen zu Speichern und dann bei Abschluss auf Band zu sichern. Klappt auch gut soweit, nur bremst das die Bandsicherung wieder extremst aus.

Da ist mir die Idee gekommen unsere Dateien Projekt- oder Kundenweise in einer sepreaten VHD Datei zu sichern und man hat dann nur noch eine große Datei die man auf Band schreiben muss, wenn man rann muss kann man die VHD ja einfach mounten.

Meine Frage nun, ist das praktikabel oder habe ich etwas nicht bedacht, Datenintegrität oder gibt es eine Alternativlösung?
Was würdet Ihr machen?

 

[BFF]

Hi,

Wir machen es aehnlich. Allerdings per VMware.
Projektdaten sind immer auf einer virtuellen Platte (.vmdk).
Wenn nicht mehr benoetigt wird die Platte ausgehaengt, die Datei wandert per Backup in das Archiv und wird nach Funktionspruefung aus dem Storage entfernt.

Da das nur ein paar mal im Monat vorkommt, ist der Aufwand nicht so extrem.

BFF

 

[snaxilian]

Habt ihr einen speziellen Grund, warum ihr auf Band sichert und z.B. nicht auf Disk? Bei Band ist es enorm wichtig, dass die Daten schnell genug geliefert werden können damit der "Streamer" am Stück alles wegschreiben kann. Daher ist eine Sicherung von Blockdevicen sinnvoller. Wenn ihr aber temporär immer Spitzen habt, habt ihr mal über Cloud-Lösungen nachgedacht wo man nur dann das zahlt, was man belegt/nutzt?

 

[sikarr]

Habt ihr einen speziellen Grund, warum ihr auf Band sichert und z.B. nicht auf Disk?

Weils günstiger ist. Ich halte die Sachen nicht unbegrenzt auf Disk vor bis der Kunde sich entschieden hat. Die Bänder sind billig und robust, liegen in einem serperaten Brandabschnitt in einem Tresor.

Bei Band ist es enorm wichtig, dass die Daten schnell genug geliefert werden können damit der "Streamer" am Stück alles wegschreiben kann.

Machen wir nicht erst seit gestern aber Danke für den Hinweis Wir wollen ja nicht von der Bandsicherung weg das passt, es geht um unsere Langzeitarchivierung.

Wenn ihr aber temporär immer Spitzen habt, habt ihr mal über Cloud-Lösungen nachgedacht wo man nur dann das zahlt, was man belegt/nutzt?

Möchtest du deine Bank-, Insolvenz-, Kranken-, Firmen- und Versicherungsakten auf einem unbekannten Server bei einem Fremdanbieter liegen haben? Den genau um solche Akten geht es.

 

[snaxilian]

Wenn ich die Daten vorher verschlüssele nicht aber ich habe mal offensichtlicher weise voraus gesetzt, dass dies selbstverständlich sei.

Reine Tapes sind relativ günstig, das ist korrekt aber mit backup to disk meinte ich eher die klassische externe HDD oder ein RDX Laufwerk. Ja, Bänder sind günstig, die Laufwerke kosten halt und ich brauche idR dazu passende Software, die die Backups auch wieder einlesen können. Bei KMUs mag dies gehen, wenn man von größeren Datenmengen im dutzende/hunderte TB Bereich redet, dann ist so eine Tape Library schon etwas teurer.

Ansonsten wie schon gesagt: Ja, eine große Datei lässt sich idR besser auf ein Tape sichern als viele kleine Dateien. Ob es dafür eine VHD sein muss oder es ggf. schon reicht, die Daten entsprechend ein eine Archivdatei (zip, rar, etc) zu verpacken wäre zu testen.

 

[sikarr]

Verschlüsselt versteht sich von selbst.
Die Idee mit der VHD kam mir nur weil:
1. ist in Win7+ integriert, kann also jeder Client öffnen
2. eine Datei pro / Projekt oder Kunde
3. leichter zu händeln

alles was aufs Band kommt hat der Kunde eh schon bekommen, hier handelt es sich nur um Archivierung für den Kunden oder Uns.

Ja es sind schon mehrere TB, die möchte ich ungern hochladen und ob das wirklich sicherer ist sei dahingestellt, ich bin kein Freund von der Cloud. Siehe die Niederlande wo ein Admin im Rechenzentrum einfach mal Kundendaten gelöscht hat.

Wir haben die Daten auf unserem Clusterstorage, von da geht es zu einem Backupserver und von dort aus gehts dann aufs Band. Und wir haben Projekt Ordner die 8 stellige Dateianzahl erreichen, oft sehr klein aber sehr viel.
Aktuell haben wir für das Verschieben von 26 Projekt Ordnern, auf dem selben Laufwerk, fast 2 Tage gebraucht.

Ich hoffte diese Zeit verkürzen zu können.

 

[BFF]

Virtuelle Datentraeger machen schon Sinn.

Die meisten Kunden bei uns betreiben selbst Virtualisierungsloesungen. Wenn dort die Daten von uns nochmals gebraucht werden solten, wird halt einfach die "Platte" eingehaengt und gut.

Ich denke, am Ende muss jeder den fuer die Geschaeftsablaufe guenstigten Weg fuer sich selbst finden.
Eventuell sogar zweigleisig, sprich bei grossen Datenmengen VHD bei kleinen halt z.B. Zip-Archiv.
Wir machen es generell auf "Platte", egal wie klein/gross die Datenmenge ist.
So bleibt der Ablauf fuer uns immer gleich fuer das Personal und Protokoll.

BFF

Ergänzung (16. November 2018)

8 stellige Anzahl von Dateien. Viel Spass beim "Zippen".

Deine Idee ist schon praktikabel, @sikarr

BFF

 

[snaxilian]

Dann scheint VHD ja eine brauchbare Lösung zu sein. V.a. wenn man z.B. gleich darin arbeitet muss man vor der Archivierung nicht erst alles hin und her kopieren.

Nur weil ich Cloud vorgeschlagen habe, befreit einen dies nicht davon, Backups zu haben, genau so wie eine VM bei Amazon/Azure/Google/Alibaba/etc nicht automatisch hochverfügbar ist. Dinge, die viele gerne vergessen/verdrängen oder einfach nicht bedenken aber das ist auch generell eher ein anderes Thema.

 

[sikarr]

Ich seh gerade das vhdx wohl das bessere Format wäre, aber ich glaube wir haben alle eh vom selben gesprochen .
vhdx lässt sich per powershell mounten was uns sehr entgegen kommt, da könnte man viel Automatisieren.
Was mir noch Kopfzerbrechen bereitet ist die Datenintegrität von vhdx. Wie robust sind die Container gegenüber ausfällen? Thema Bit Rot, weis da einer was?

 

[snaxilian]

Das ist eher ein Problem deines zugrunde liegenden Storages. Da HyperV für seine VMs ja auch VHDX Files verwendet, kann man schon sagen, dass es recht robust ist wenn man es korrekt verwendet. Ein kippendes Bit oder auch Bit Rot eben, musst auf auf Ebene deiner Speichermedien lösen. Im Optimalfall hast du also zugrunde liegende fehlerkorrigierende Dateisysteme (ReFS, ZFS, BTRFS, o.ä.) oder musst dich eben selbst um Checksums und Paritäten für eine eventuelle Korrektur kümmern. Fertige SAN/NAS-Lösungen im Enterprise Bereich haben so etwas natürlich idR auch (NetApp, Dell Compellent, usw. usf)

 

[sikarr]

Gibt es ein Limit für LTO6 Bänder was Elementanzahl beträgt? Wir haben ein Band mit 11.000.000 Dateien und derbe Probleme bei der Wiederherstellung mit Acronis.

 

[snaxilian]

Nein, das reine Band hat da keine Limitierungen, da LTO LTFS als Dateisystem verwendet. Hier wird eher euer Backup-Programm limitieren, da es vermutlich versucht, den kompletten Index und Metadata aller Dateien auf dem Band einzulesen. Entweder ist der Backupserver am Limit was RAM o.ä. angeht oder die Software limitiert da eher...

 

[sikarr]

Der Backupserver hat Tagsüber keine Last, das passiert alles Nachts. Resourcen sollten genug da sein ist ein 6 Kerner mit 12 Threads und 64Gb Ram + Storage. Man kann zugucken wie er die Bits schreibt, und die Kiste Langweilt sich dabei.

Wir bauen wie gesagt alles gerade auf vhdx-Container um, pro Projekt eine vhdx, aber das dauert. Das Band enthält noch die alte Ablage, viele Ordner viele Dateien.

 

[snaxilian]

Direkt einzelne Dateien und Ordner auf ein Band schreiben ist alles aber nicht best practice. Für eine sinnvolle Nutzung von Bändern sollte man immer komplette Volumes, Container etc dahin schreiben damit konstant geschrieben und gelesen werden kann. Gerade viele kleine Dateien einzeln schreiben verkürzt die Lebenszeit und Performance von LTOs deutlich und sollte vermieden werden.

"Ressourcen sollten da sein" ist ja mega schwammig. Was sagt euer Monitoring? Werden alle Kerne/Threads genutzt während der Sicherung oder nur einer oder manche? Wie ist die RAM-Auslastung? Auslastung der Dateisysteme von wo die Backups gelesen werden? Gibt es eine Performance-Auswertung der Backup-Jobs? Gibt es Logs der Anwendung, die ggf. auf den Flaschenhals hindeuten können?

 

[sikarr]

Ich hab ja bereits geschrieben das wir die Backupstrategie gerade entsprechend ändern, vorher wurde sich immer dagegen gesträubt aber ich habe nun mehr Freiheiten durch interne Änderungen und kann sowas schneller umsetzten.

 

[sikarr]

Band liest immer noch, der Katalog ist 330Gb groß, haben aktuell 700Gb wiederhergestellt. Bevor wir das in Container packen können müssen wir das Band auslesen, Teufelskreis