News Absatzrekord: 148 Exabyte Bandspeicher ausgeliefert

Miuwa schrieb:
Mir ist schon klar, wie es prinzipiell funktioniert und dass der Wahlfreie Zugriff damit extrem langsam ist. Was mir nicht klar ist, ist warum ich für die Wiederherstellung wahlfreien Zugriff brauche.
Denk einfach mal an inkrementelle oder differentielle Backups, wenn sie auf einem Band wären. 🙂 Oder wenn Du mehrere kleinere Dateien hast, die Du wieder herstellen willst.
 
PHuV schrieb:
Denk einfach mal an inkrementelle oder differentielle Backups, wenn sie auf einem Band wären. 🙂 Oder wenn Du mehrere kleinere Dateien hast, die Du wieder herstellen willst.
Für mehrere klein Dateien brauche ich keinen Wahlfreien Zugriff, wenn sie zusammen liegen.

Inkrementelle Backups müssen ohnehin in der Reihenfolge ausgelesen werden in der sie angelegt wurden (wahlfreien Zugriff brauche ich da nur auf der Zielfestplatte) und bei differenziellen Backups will ich zwar alte Versionen überspringen, aber auch hier gehts eigentlich nur in eine Richtung.

Ich mein, wenn ich ein Backup auf ein Band mache, dann nutze ich das Band ja nicht so, wie ne NTFS-formatierte Festplatte auf die ich durch Copy-Paste meinen Home-Folder ablege. Ich würde doch erwarten, dass Backupsoftware da etwas intelligenter vorgeht.
Und wenn ich nach einem Ausfall den Inhalt einer Sicherung wiederherstellen muss, dann kopiere ich ja auch nicht Datei für Datei in zufälliger Reiehnfolge einzelnd zurück, sondern kopiere halt das ganze Image in einem Rutsch.

Wie schon gesagt: Ich hab keine praktische Erfahrung damit, aber mir scheint, falls ich beim Backup oder bei der Wiederherstellung tatsächlich groß wahlfreien Zugriff auf dem Band brauche, dann hat der Entwickler der Backup Software seine Hausaufgaben nicht gemacht.
 
Genau deswegen ist ja heute das Backup2Disk2Tape das was bevorzugt gemacht wird. Direkt auf Band sichern duerfte heutzutage eine Ausnahme sein.

Das Band brauchst du dann fuer die Wiederherstellung nur, wenn die Daten schon laenger weg sind.
Ja, das passiert - User die vorm dreiwoechigen Urlaub nochmal "kurz aufraeumen" kommen erschreckend oft vor.
Oder halt beim echten Disasterrecovery, wenn es das Storage, wie auch immer, zerlegt hat.

Wir haben dann auch entsprechende (lockere) SLAs: Daten die noch auf den zwei Wochen vorgehaltenen Snapshots liegen stellen wir in der Regel innerhalb kurzer Zeit wieder her. Ist es aelter, und liegt auf Tapes innerhalb der Library, haben wir schon mindestens einen Werktag Zeit dafuer. Sind die Tapes ausgelagert (Verlust laenger her als einen Monat), dann setzen wir zwei Tage an.

Ist es aelter als 6 Monate, laeuft es in einen anderen Prozess, dann zaehlt es offiziell als Wiederherstellung aus dem Archiv. Da haben wir individuelle Wiederherstellungszeiten. Teilweise auch, weil wir fuer die ganz alten Daten noch alte Software brauchen, und ggf. sogar noch alte Hardware in Betrieb nehmen muessen.

Tapes bringen da naemlich ein gewisses Problem mit: In den Augen der Entscheider wird, dadurch das die Tapes so haltbar sind, es schnell als Alternative gesehen, die Tapes einfach lange im Schrank liegen zu lassen, und das Backup so als Archiv zu missbrauchen. Das faellt einem aber nach ein paar Jahren auf die Fuesse: Spaetestens wenn 2 Generationen LTO Technologie uebersprungen wurden, kommt man an das "Archiv" nicht mehr dran. Und die alte Hardware nimmt im Lager so viel Platz weg, das man alles entsorgen muss.
Oder man wechselt die Backupsoftware, weil der Hersteller sich plotzlich nach Datenvolumen bezahlen lassen will. Oder man wechselt das Storagesystem, und alle NDMP Backups sind ploetzlich wertlos...

Ja, alle diese Szenarien habe ich mitgemacht, als ich noch Backup Verantwortlicher war, der aber keine finanziellen Entscheidungen treffen durfte.
 
Wahlfreien Zugrif auf Band ... das macht keine Backupsoftware. Zumindest nicht bei einer vollständigen Wiederherstellung. Und bei einer selektiven Widerherstellung von Daten wird auch sequentiell vorgegangen, aber nicht benötigtes übersprungen.

Vor zig Jahren hatte ich mal, ergänzend zu meiner damaligen Backup-Lösung, eine Software die es ermöglicht hat, unterstützte Tape-Laufwerke als Windows-Laufwerk zu mounten. Ich habe das damals mit meinem DAT-Streamer mal ein wenig versucht. Es hat schon funktioniert, war aber in der Praxis wenig brauchbar. Bestenfalls für ganz selten benötigte Dateien. Und eilig durfte man es nicht haben.

Ich glaube die Option gab oder gibt es auch noch bei LTO Tapes. Aber da dürfte das auch ein absolutes Nischendasein führen. Edit Zusatzinfo: Linear Tape File System (LTFS)
 
Zuletzt bearbeitet:
Miuwa schrieb:
Für mehrere klein Dateien brauche ich keinen Wahlfreien Zugriff, wenn sie zusammen liegen.
Und wie willst Du das im Falle eines Recovery so zusammenstellen, wo welche Dateien dazugehören, so daß sie logisch hintereinander liegen? Du brauchst nur Dateien in verschiedenen Ordnerstrukturen haben, und schon hast Du den Salat.
Miuwa schrieb:
Wie schon gesagt: Ich hab keine praktische Erfahrung damit
Nicht böse gemeint, aber das merkt man. Glaubs mir einfach, es dauert wesentlich länger als über eine Festplatte oder SSD.
 
PHuV schrieb:
Und wie willst Du das im Falle eines Recovery so zusammenstellen, wo welche Dateien dazugehören, so daß sie logisch hintereinander liegen? Du brauchst nur Dateien in verschiedenen Ordnerstrukturen haben, und schon hast Du den Salat.
Verstehe das Problem nicht. I.d.R. will ich doch die Dateien zusammen wieder herstellen, die ich auch zusammen gesichert habe. Wüsste auch nicht, was die Ordnerstruktur mit der physischen Organisation der Datem zu tun hat.
Und gerade bei Tapes reden wir ja primär davon ganze Volumes zu sichern und wieder herzustellen.


PHuV schrieb:
Nicht böse gemeint, aber das merkt man. Glaubs mir einfach, es dauert wesentlich länger als über eine Festplatte oder SSD.
Ich glaube dir ja, dass es langsamer als mit HDDs ist (wo kommt plötzlich der vergleich mit der SSD her?) Meine Frage ist warum das so ist (über irgendwelche evtl vorhandenenUnterschiede in der sequenziellen schreib/leserate hinaus).
 
Zuletzt bearbeitet:
Zuletzt bearbeitet:
  • Gefällt mir
Reaktionen: Archivar
MountWalker schrieb:
Wie viele ältere Versionen einer Datei hebst du auf?
Unendlich (bzw 14 Tage, 12 Monate und 3 Jahre, also nicht Anzahl der Kopien). Ich nutze rsync mit Zeitstempelordnern.

Allerdings ist das vom Prinzip egal. Selbst wenn ich nur ein paar Kopien zulassen würde, würde die Ransomware ja alles verschlüsseln und damit wurde bereits das erste Backup 100% mehr Speicherplatz belegen. So viel Platz hab ich gar nicht auf dem Backupserver. Der würde dann voll laufen und ich bekäme einen E-Mail Alert wegen voller Festplatten.
 
Miuwa schrieb:
Verstehe das Problem nicht. I.d.R. will ich doch die Dateien zusammen wieder herstellen, die ich auch zusammen gesichert habe. Wüsste auch nicht, was die Ordnerstruktur mit der physischen Organisation der Datem zu tun hat.
Und gerade bei Tapes reden wir ja primär davon ganze Volumes zu sichern und wieder herzustellen.
Nope. Bei den Firmen werden oft auch die Dateiserver für die unterschiedlichen Bereiche gesichert (Verwaltung, Sekretariat, Buchhaltung usw.). Und nun willst Du nur einzelne Dateien von einem Band wieder herstellen, die in zig unterschiedlichen Ordnern liegen. Da hast Du keine zusammenhängende Dateien, die Du in einem Rutsch zurücksichern kannst. Mittlerweile gibts ja intelligentere Techniken zum Sicherung und Recovern (Versionierung, Schattenkopien, Dateiversionsverlauf etc.), die beispielsweise in OneDrive, Sharepoint und selbst in Windows eingestellt werden können. Davor war es echt ein Akt, wenn die Sekretärin irgendwelche Dateien verschlampt oder kaputt gemacht hatte, und man sie wieder von Band rücksichern mußte.
Miuwa schrieb:
Ich glaube dir ja, dass es langsamer als mit HDDs ist (wo kommt plötzlich der vergleich mit der SSD her?)
Weil wir das mittlerweile auch als Backupmedium benutzen. SSD ist leichter als eine HDD und nun ja auch mit großen Speicherplatz verfügbar (1-8 TB) und günstiger geworden.

Nach Backupstrategie sollte ja immer ein Backup außen lagern. Daher hat ein Admin der Woche die Aufgabe, von allen wichtigen Bereichen ein HDD und ein (verschlüsseltes) SSD Backup zu erstellen und im wöchentlichen Wechseln mit nach Hause zu nehmen. Und wie gesagt, eine SSD ist leichter mitzunehmen als eine SSD.

Nur zur Erinnerung, wir sprechen von einem kleineren Unternehmen, was sich kein dickes Tapesystem hinstellen will! Wir hatten vor 11 Jahren so Iomega Möhren, wo die Rücksicherung wirklich lange brauchten, und das habe ich bei uns alles nun durch HDDs und SSDs, teilweise Cloud abgelöst. Wie gesagt, die Rücksicherung erfolgt dann hier für einzelne Dateien in Sekunden, sobald der Datenträger in den Wechselrahmen eingeschoben wurde. Da in mehreren Generationen gesichert wird, kann man sogar sofort das entsprechende Datum und KW ermitteln. Per Band ist erst mal Suchen und Spulen angesagt.
 
Zuletzt bearbeitet:
mgutt schrieb:
Unendlich (bzw 14 Tage, 12 Monate und 3 Jahre, also nicht Anzahl der Kopien). Ich nutze rsync mit Zeitstempelordnern.

Allerdings ist das vom Prinzip egal. Selbst wenn ich nur ein paar Kopien zulassen würde, würde die Ransomware ja alles verschlüsseln und damit wurde bereits das erste Backup 100% mehr Speicherplatz belegen. So viel Platz hab ich gar nicht auf dem Backupserver. Der würde dann voll laufen und ich bekäme einen E-Mail Alert wegen voller Festplatten.
So hatte ich das auch lange laufen. Je nachdem, wie die Verschlüsselung implementiert ist, bekommt rsync das aber gar nicht mit. In meinem Fall wurden Dateien (durch ein "gutes" Programm) in place verschlüsselt, wobei die geänderte Datei und unter Beibehaltung des Dateinamens, der Dateigröße und aller Zeitstempel gespeichert wurde. Rsync hat sich dann die Übertragung geklemmt und auf dem Zielsystem einfach wie vorgesehen einen Hard Link auf die dort bereits vorhandene Version aus dem letzten Snapshot gesetzt. Dadurch waren solche Dateien im Backup beliebig alt wenn man nicht aufgepasst hat. Im Ransomware Fall wäre das natürlich nicht ganz so nachteilig...
 
Zuletzt bearbeitet:
Purche schrieb:
wobei die geänderte Datei und unter Beibehaltung des Dateinamens, der Dateigröße und aller Zeitstempel gespeichert wurde. Rsync hat sich dann die Übertragung geklemmt und auf dem Zielsystem einfach wie vorgesehen einen Hard Link auf die dort bereits vorhandene Version aus dem letzten Snapshot gesetzt. Dadurch waren solche Dateien im Backup beliebig alt wenn man nicht aufgepasst hat. Im Ransomware Fall wäre das natürlich nicht ganz so nachteilig...
Gut zu wissen. Wobei es wie du schon sagst, keinen Nachteil resultiert.

Übrigens plane ich 1x pro Monat statt Datum+Größe per Checksum zu sichern. Auch einfach um bit rot zu erkennen. Der Plan wäre erst ein normales Backup zu machen und dann direkt noch eins mit Checksum und dann ein E-Mail Report zu generieren, sofern neue Dateien gesichert wurden. Wobei ich gerade wegen Dockern da noch nicht sicher bin wie ich das mache ohne immer Reports zu erhalten (weil sich da ja immer irgendwas ändert und sei es nur eine Logfile).
 
PHuV schrieb:
Nope. Bei den Firmen werden oft auch die Dateiserver für die unterschiedlichen Bereiche gesichert (Verwaltung, Sekretariat, Buchhaltung usw.). Und nun willst Du nur einzelne Dateien von einem Band wieder herstellen, die in zig unterschiedlichen Ordnern liegen. Da hast Du keine zusammenhängende Dateien, die Du in einem Rutsch zurücksichern kannst. Mittlerweile gibts ja intelligentere Techniken zum Sicherung und Recovern (Versionierung, Schattenkopien, Dateiversionsverlauf etc.), die beispielsweise in OneDrive, Sharepoint und selbst in Windows eingestellt werden können. Davor war es echt ein Akt, wenn die Sekretärin irgendwelche Dateien verschlampt oder kaputt gemacht hatte, und man sie wieder von Band rücksichern mußte.

Ok, korrigiere mich, wenn ich falsch liege, aber das Klingt nach dem Anwendungsfall "User hat irgendwelche Dataien aus versehen gelöscht oder Überschrieben und weiß schlimmstenfalls noch nichtmal wo genau die Datei lag".
Falls das der Fall ist, dann ist klar woher mein Unverständnis kommt: Ich kenne Band nur entweder zum Archivieren (aus rechtlichen Gründen, nicht weil man da normal wieder ran muss) oder für Desasterrecovery. Also Brand im Serverraum / Kaputtes NT grillt auch die Fesplatten / Admin macht ein "rm -rf " im falschen Verzeichnis, Verschlüsselungstrojaner etc ...
Das mag an meinem Alter oder den Firmen liegen, aber ich hab bisher noch nirgends gearbeitet, wo es nicht zumindest eine direkte Fallbackebene für die oben genannten Nutzerfehler gab (Heute direkte Versionierung über die von dir genannten Methoden, früher halt nen Backup Server den man durchsuchen konnte). Dass man Band schon für diese Ebene verwenden kann hab ich nicht bedacht.
 
Zuletzt bearbeitet:
  • Gefällt mir
Reaktionen: Skysnake und Nore Ply
@Miuwa: So hat meine Firma frueher gearbeitet. Wir hatten, auf unsere Firmengroesse (und Finanzen) gerechnet schon immer ueberdurchschnittlich viele Daten.
Damals war ein separates Storage fuers Backup nicht drin. Tape-Backup (Damals noch LTO-2) brauchten wir aber so oder so.
Versionierung hat auf den damaligen Windows 2003 Fileservern mit den SCSI DAS Shelves einfach zu viel Performance gekostet.

Also wurden nicht nur die Fulls am Wochenende auf Tape gezogen, sondern auch die Differentials in der Woche.

Natuerlich konnten wir aber in der Backupsoftware (Veritas/Symantec Backup Exec) suchen. Alles andere waere ja auch maximal unsinnig gewesen :D
Man klickerte sich also seine Restoreliste zusammen, hat von BE die Liste an benoetigten Tapes bekommen, und legt sie in die Library ein. Der Rest war dann automatisch.

Das groessere Problem waren aber nicht die File-Backups. Sondern die vom Exchange.
Man konnte zwar auch die Exchange Backups bis zu den Email-Metadaten (Subject, Empfaenger, Uhrzeit) durchsuchen. Wollte man aber Emails wiederherstellen, musste Backup Exec die gesamte Exchange Datenbank wiederherstellen. Das brauchte ein genuegend grosses Temp-Verzeichnis, die Software hat aber nie gesagt wie gross dieses sein muss :D
 
Zurück
Oben