Home > backup > Backup – Auf der Suche nach einem Konzept

Backup – Auf der Suche nach einem Konzept

19. März 2009

Backup war noch nie mein Thema, darum macht es mir auch solche Knoten im Kopf. Ein Konzept a la ‚Ein Client sichert über Server auf ein Band‘ ist so dermaßen veraltet, das es sich nicht lohnt irgendeinen Gedanken daran zu verschwenden. Aber wie sieht denn ein modernes Backup-Konzept aus?

Geht man den Weg des Hypes kann man schnell Bullshit-Bingo gewinnen. VTL, Serverless-Backup, Snapshot und Deduplizierung. Bing, Bing, Bing. Und Bonus-Punkte gibt es für Tape backup is dead. Verkompliziert wird das ganze noch durch meine Meinung zu kommerzieller Backup-Software. Sei es ArghServe, NichtBackup oder anderes – mir gehen dabei zumeist die Nackenhaare hoch. Aber mal der Reihe nach:

Tape backup is dead: Nein, ist es nicht. Die Sicherung auf Band ist für mich die letzte Sicherungslinie, wenn alles andere versagt hat. Es soll Firmen geben, die nicht mehr auf Band sichern. Sie verlassen sich auf Backup-to-Disk und/oder VTL. Grob Fahrlässig, wie ich finde, denn sollte einmal etwas mit der Software-Only Lösung sein (Ja, auch WAFL und ZFS können kaputt gehen) wird der Hersteller zuerst fragen, ob man denn ein Backup hat. Meine Daten bringt soetwas nicht wieder. Dann lieber in den Schrank greifen und das Band rausholen.

VTL: Irgendwie will sich mir nicht erschließen welches Problem eine VTL lösen soll. Zugegeben, wenn eine VTL mit Hardware-Komprimierung und Deduplizierung arbeitet lassen sich erstaunliche Datenmengen auf kleinsten Raum speichern, nur wenn ich damit auf Tape möchte ist der Vorteil dahin. Das komprimierte, deduplizierte Ergebniss auf Tape zu ziehen wäre für den K-Fall fatal. Man müßte aus den Bändern erst die VTL wiederherstellen um dann das eigentliche Desaster-Recovery zu starten, das dauert viel zu lange und ist eine mögliche Fehlerquelle zuviel. Irgendwie verglängert sich der Backup-Prozess immer mehr. Primäre-, Sekundäre-Storage, VTL und dann Tape. Spannend dürfte auch die Frage der Kosten sein. Eine VTL kostet unter Umständen eine Stange Geld und man darf nicht vergessen das Backup-Software oft nach Anzahl der Laufwerke und Slots lizensiert wird. Da mag es zwar schön sein, das man 512 SAN-Laufwerke und mehrere tausend Slots mit der VTL emulieren kann, freuen wird das aber nur den Vertriebler der Backup-Software.

Snapshot: Ein Snapshot hat für mich nicht direkt etwas mit Backup zu tun. Klar, es ermöglicht eng beieinander liegende Wiederherstellungspunkte. Eine Stunde ist mit Band unrealistisch, aber trotzdem eine realitätsnahe Anforderung. Zu vergessen sind auch nicht die großen Katastrophen. Wenn es Probleme innerhalb der Storage gibt sind auch schnell die Snapshots weg. Hier wäre imho vielleicht ein Stufenmodell angebracht. Innerhalb eines Tags Snapshots, für den K-Fall den letzten Tag auf Band.

Deduplizierung: Innerhalb einer Appliance macht das noch Sinn. Aber eine Backup-Software, die extra Metadaten für die Deduplizierung irgendwohin schreibt? Schonmal jemand einen Backup-Server aus einen Backup wiederhergestellt? Guter Witz.

Serverless-Backup: Wer auf Full-Backups forever steht, bitte. Ich hab da so meinen Bedenken.

Nun besteht die Welt aber leider nicht nur aus Servern. Große, kleine und mittlere Storage-Systeme sind weit verbreitet, aber wie sieht es da mit dem Desaster-Recovery aus? Gründe warum so ein System versagen kann gibt es mehr als man denkt und nichts ist fataler als viele, viele TB auf einen NAS-System zu haben und nicht heranzukommen. Es gibt NDMP oder propritäre Sachen wie SnapMirror to Tape. Das eine ist File-, das andere Block-basiertes Backup. Beides hat seine Anwendungsgebiete und damit seine Berechtigung.

Um etwas den Knoten zu entwirren habe ich angefangen Backup & Recovery von W. Curtis Preston zu lesen. Ich bin noch nicht weit, aber die ersten zwei Kapitel sind allein ihr Geld wert. Darin geht es um grundsätzliche Fragen, wie zum Beispiel das Excluden besser ist als Includen oder das wenn man wenig zu verlieren hat, wenn man alles sichert, dafür aber unendlich viel Arbeit, wenn man immer nur das nötigste sichern will.

In dem Buch gibt es auch ein Kapitel über Amanda, welches ich mir auch gerade anschaue. Macht einen guten Eindruck. Man kann mit tar & gzip oder dump auf dem Client arbeiten und auf Tape oder Disk sichern oder beides aufeinmal. Clients sind für alle wichtigen Betriebssysteme vorhanden. Charme hat das Format der Sicherung. Notfalls kann man ohne Backup-Server wiederherstellen oder Linux Bare-Metal recovern über eine Knoppix-CD. Auch die Komprimierungs-Rate durch gzip ist nicht zu verachten.

Sorry, wenn das da oben ein paar Gedankensprünge enthält, aber diese Lücken sind ja gerade das Problem. Ich könnte mir vorstellen das ‚Problem‘ zwei zu teilen. Backup to Disk für die Clients mit Amanda und das Desaster-Recovery der Filer für mit einer Software auf Tape, die gut mit den Features der Filer klarkommt. Aber ich vermute einfach mal so einfach bleibt es nicht.

Tags:

  1. Dragoslav
    19. März 2009, 23:00 | #1

    VTLs haben durchaus ihre Daseinsberechtigung. Bänder sind toll wenn man von einem Server einen kontiuierlichen Datenstrom bei konstant hoher Durchsatzrate bekommt. Bei vielen Servern die in der Nacht alle gesichert werden sollen und nebenbei irgendwelche (un)wichtigen Tätigkeiten verrichten wird es verdammt schwer echte Streamer(pools) voll auszulasten. Bei den nicht gerade kleinen Backupvolumen die heute so in Rechenzentren versteckt sind dauert ein Backup plötzlich sehr sehr lange. Auch ein Grund warum Backup so unbeliebt ist.
    Die VTL nimmt sich dem „Verkehrschaos“ an und sichert alles auf virtuelle Tapes. Limit ist nun nicht mehr der liefernde Server (der ja einen echten Streamer belegen würde) sondern eigentlich nur noch die Bandbreiten und Storagekapazität/Geschwindkeit des Backupservers. Damit kriegt man die Backupzeitfenster auf passable Zeiten runter. Da man natürlich nicht auf echte Bänder verzichtet (zumindest für wichtige Geschäftsdaten) kann man tagsüber diese Daten aus der VTL optimiert auf echte Tapes bannen. Gerade bei den großen Backupmengen kann man hier auch nochmals schön entscheiden welche Daten wirklich auf Band archiviert werden müssen und was man nur für ein schnelles Recover braucht aber auch mal verlieren darf. z.B. Betriebssystem und Standardsoftware dürfen ruhig in der VTL verbleiben und Deduplizierung spart hier wieder Storage und damit Geld.
    Der Rückweg – also das Restore – ist bei der Nutzung von VTLs ein Unterschied wie Tag und Nacht. Wenn mal was kaputt geht oder versehentlich gelöscht wird was sich im vorherigen Backup befindet hat man unglaublich kurze Restorezeiten: Backupclient öffnen, Dateien wählen, Restore starten, und schon fertig. Geht fast so schnell wie vorher die DAten vernichtet wurden :-)
    Man muss nun keine halbe Stunde mehr warten bis 1. ein Streamer frei ist, 2. der Bandroboter unser Medium sucht, 3. das Band bis ans Ende vorgespult wird, 4. endlich der Restore gemacht wird.

    Wie in allen Architekturen ist es die Vielschichtigkeit die Dinge kompliziert und risikobehaftet macht. Das gilt für Applikationen, Storage und eben auch den zugehörigen Backups. Meistens zwingen einen irgendwelche harten Anforderungen (Skalierbarkeit, Performance, Restorezeiten) in eben diese Architekturen.

    Gute Nacht

  2. Strike
    20. März 2009, 09:54 | #2

    Der fuer mich entscheidene Vorteil der VTLs ist, das ich die ueber FC anbinden kann (und auch habe ;) ) somit stehen mir 2/4/8 GBits zur Verfügung wohingehend beim LAN entweder 1Gbits oder teuere 10GBits geboten werden. Die dahinterstehende Infrastructure (SAN) sollte natuerlich dafuer ausgelegt sein.
    Tapes (physische) sind auf Grund behördlicher Regulatorien wichtig und gelten immer noch als letzter Rettungsanker, dem K-Fall (oder auch Desaster Fall) beugt man besser mit einem repliziertem Sicherungsbestand (VTL B2D D2D (Bullshitbingo as its best)) vor.

    Zum Thema Deduplizierung darf ich im moment nichts öffentlich schreiben

    gruss
    Stefan

  3. Eule
    20. März 2009, 10:56 | #3

    Dragoslav hat eigentlich so ziemlich alles Wichtige gesagt. Trotzdem geb ich auch nochmal meinen Senf dazu. :)

    Oft werde ich mit Umgebungen konvertiert, wo dass Zeitfenster fürs Backup nicht mehr passt oder kein konstanter Stream zu Stande kommt (Stichwort Start-Stop Modus)

    Wenn das nötige Kleingeld vorhanden ist, sieht die einfachste Lösung so aus, dass ich ein mehr stufiges Backup fahre. Nachts übertragen meine Server etc. ihre Daten auf eine VTL, was dank hunderter gleichzeitiger Jobs kein Zeitproblem darstellt (im Gegensatz zu einer Tapelib.) und Tagsüber sichert die VTL das ganze auf Tape. Die VTL kann wiederum das Tape ausreichend auslasten, so dass wir einen durchgehenden Stream haben.

    Was Dedup. im Restorefall angeht hast du recht, natürlich dauert ein Restore in diesem Falle dann länger. Da muss man einfach abstimmten, was ist wichtiger? Platzsparen beim Backup oder Zeit sparen im Desaster Fall?

    Achja und mit VTL sprichst du sicher von der Netapp Lösung oder? Zugegeben ich bin ein großer Netapp Fan aber die VTL halte ich für sagen wir nicht soooo toll. Was nützt mir eine dedup Funktion bei einer VTL wenn sie keine inline Deduplizierung beherrscht? Sprich: Toll Jungs ihr könnt ganz toll deduplizieren wenn die Daten auf dem Gerät sind… aber zum Übertragen brauche ich trotzdem genauso viel Speicherplatz auf dem Ziel wie auf den Quellen. 2 Daumen nach oben :(

    Thema Snapshot: Ein Snapshot ersetzt kein „richtiges“ Backup. Ich habe Kunden die sagen mir „Wow wir machen alle 30min ein Snapshot von unserem System da brauchen wir ja kein Tape mehr“ bei so was stehen mir die Haare zu Berge (und ich habe nicht wenige)….

    Also, das Tape ist noch lange lange nicht Tod! (Nur für Kunden mit Zuviel Geld kann man ein Konstrukt entwerfen welches völlig ohne Tapes auskommt)

  4. 20. März 2009, 19:48 | #4

    VTLs sind Mist, außer man legt Wert auf Dedup oder einen schnellen Restore. Ohne Sicherung auf Band ist man im K-Fall eh ziemlich verloren. Bezüglich Streaming: Alles eine Frage der Software. ;) Wenn ich genügend Agenten fliegen habe, dann bekomme ich jedes Laufwerk gefüttert. Ich kann mir natürlich auch dank LAN-free Backup toll die Karten legen. Alles in allem gibt es kein Patentrezept. Ich habe teilweise recht große Backupumgebungen designed, auch ohne echte Zeitfenster. Eine Lösung gibt es immer. Alle eine Kombination aus Performance, Verfügbarkeit und Geld.

  5. 20. März 2009, 20:49 | #5

    @Dragoslav: Was Du beschreibst passt für mich auch auf Backup-to-Disk, da brauche ich keine VTL für.
    @Strike: 10GB Ethernet und FC-SAN geben sich (noch) preislich nicht viel, nur das Ethernet wesentlich flexibler einzusetzen ist als FC.
    @Eule: Ich empfinde das native Tape-Format der NetApp-VTL gerade als Vorteil.

  6. 24. März 2009, 12:20 | #6

    Ich habe mit Bändern an sich auch gute Erfahrungen gemacht. Mein Problem sind die Laufwerke. Mit – genauer gesagt meinen Kunden – ist es schon mehrmals passiert, daß gerade dann wenn man ein Restore gebraucht hätte, dann das Bandlaufwerk seinen Geist aufgegeben hatte. In einem Fall war dann nicht einmal mehr ein Ersatzgerät aufzutreiben und da war dann wirklich Feuer am Dach.

    Angesichts dieser Probleme habe ich mich vor etwa zwei Jahren umgesehen welche Alternativen es gibt und bin bei Bacula gelandet. Das Ding kann auf alles mögliche sichern, wird mit einem Text-Editor konfiguriert und bietet Clients für alle wichtigen Betriebssysteme. Man kann unterschiedliche Sicherung-Profile für verschiedene Arten von Clients (Arbeitsplätze, Datenbank-Server, Exchange-Igits, etc.) definieren und im Zweifelsfall auch wenn einem die Bacula Installation abhanden kommt, alleine aus den Sicherungen „zu Fuß“ die Daten wiederherstellen.

    Und es ist ein freies OpenSource Projekt. Man braucht zwar ein wenig bis man sich eingearbeitet hat, aber wenn die Grundinstallation läuft ist es ein Klacks weitere Clients bzw. Ziele einzubinden. Ich kann es nur empfehlen und es kann auch mit Bandlaufwerken umgehen.

  7. 24. März 2009, 21:01 | #7

    @Sascha Vogt
    Bacula steht auf meiner Liste wenn Amanda versagt

Kommentare sind geschlossen