Cliffhanger: Die Backups sind richtig ... hier ... richtig?

Backups haben bei meiner Arbeit eine überraschend niedrige Priorität. Die Sicherungsstrategie wurde vor einiger Zeit implementiert, und seitdem wird davon ausgegangen, dass die Sicherungen in Ordnung sind. Wenn Sie die Sysadmins fragen, werden sie sagen, dass alles gesichert ist.

Wenn Sie jedoch nach einer SPEZIFISCHEN Sicherung fragen, ist die Hälfte der Zeit vergangen, in der sie nicht vorhanden sind:

• Die Festplatte ist voll
• Das Band ist ausgefallen
• Anscheinend hat jemand den Sicherungsjob deaktiviert
• Die Netzwerkverbindung war ausgefallen
• Wir haben diesen Datenträger vor Jahren bestellt, aber die Bestellung wurde von der Finanzabteilung nicht genehmigt
• Die Dateien sind beschädigt
• Datei enthält falsche Datenbank
• Nur Transaktionsprotokollsicherungen (ohne vollständige Sicherung nutzlos)

Vor ein paar Wochen war die Katastrophe wirklich zu Ende, als einer der Server eine zu hohe Anzahl an Raid-Festplatten verlor. Zum Glück war eine Festplatte immer noch gut genug, um die Daten zu kopieren, wenn Sie es oft versucht haben.

Aber auch nach dieser Katastrophe kann ich die Sysadmins nicht davon überzeugen, die Situation zu verbessern. Also frage ich mich, irgendwelche Tipps zum Öffnen der Augen von Menschen? Mir scheint, wir laufen am Rand einer Klippe entlang.

Man muss diese Dinge immer von oben reparieren lassen.

Wird die aktuelle Sicherungsstrategie vom Management unterstützt und verstanden? Wenn nicht, ist es nutzlos.

Die Geschäftsleitung muss über die Probleme und die damit verbundenen Risiken Bescheid wissen (Verlust von Finanzdaten, die Sie legal veröffentlichen müssen, um zu überleben, oder Daten von Kunden, deren Erfassung Jahre gedauert hat?) Und diese bei der Entscheidung über Maßnahmen oder Entscheidungen abwägen jemanden (wie dich) handeln lassen.

Wenn Sie nicht zum Management gelangen können, versuchen Sie es mit Business Controllern oder anderen Finanzpositionen, bei denen das Abrufen von Daten und deren Integrität für die Unternehmensberichte von hoher Bedeutung ist. Sie können ihrerseits bei Bedarf "den Sturm starten" ...

Wo soll ich anfangen? Dies ist eine Katastrophe, die darauf wartet, passiert zu werden. Eine Hauptaufgabe von Sysadmins besteht darin, sicherzustellen, dass Daten gesichert und wiederhergestellt werden können. Alles andere ist zweitrangig. Nein, wenn nein, aber.

Hier sind einige Dinge, die Sie tun können:

1. Verfolgen Sie KPIs für Wiederherstellungen. Es sollte möglich sein, einen Bericht zu erstellen, aus dem hervorgeht, wie viele Anforderungen für Wiederherstellungen erfolgreich waren. Alles, was unter 100% liegt, sollte gründlich untersucht werden. Management Liebesberichte und das ist ein harter Beweis.

2. Es sollten dokumentierte Verfahren für alle Sicherungs- und Wiederherstellungsvorgänge vorhanden sein, einschließlich aller Systeme und ihrer Sicherungsstrategie, Bandrotationen, Zeitpläne, Eskalationspfade, Testwiederherstellungen usw. Fragen Sie nach, um sie anzuzeigen.

3. Sprechen Sie mit dem Manager der Systemadministratoren und äußern Sie Ihre Bedenken. Bewaffnen Sie sich mit dem Beweis, dass Wiederherstellungen nicht funktionieren. Wenn keine Freude höher geht.

Ernsthaft - machen Sie viel Aufhebens. Solche Dinge können ein Unternehmen zerstören.

Schlagen Sie (mindestens) jährliche Disaster Recovery-Tests vor. Die für die erfolgreiche Durchführung des Tests erforderliche Arbeit sollte Mängel aufdecken.

Wo ich arbeite, haben wir eine wirklich gute IT-Abteilung. Jedes Jahr kommen sie aus jedem Büro in Europa zusammen und veranstalten ein "Wiederherstellungsfest" für gemietete Server in einem Rechenzentrum, um effektiv zu simulieren, was passieren würde, wenn die Mitarbeiter eines Tages zur Arbeit kämen und das finden würden Büro war in der Nacht niedergebrannt.

Bitten Sie den großen Chef, ihn daran zu erinnern, dass er im Falle einer Katastrophe in diesem Jahr keinen Bonus mehr hat (oder noch schlimmer!), Und es wäre daher ratsam, eine ähnliche Disaster Recovery-Übung zu organisieren. Es sollte nicht lange dauern oder viel kosten - Administratoren werden mit ihren Offsite-Sicherungsbändern weggeschickt und aufgefordert, eine identische Büroumgebung von ihnen aufzurufen.

Dann lehnen Sie sich zurück und sehen Sie zu, wie die IT besser wird - sobald das Management feststellt, dass die Unternehmensdaten gefährlich nahe daran sind, dauerhaft verloren zu gehen, fliegen Funken (von den Raketen, die strategisch in den Admins platziert werden).

Es ist leicht, den Admins die Schuld zu geben - aber Oskar hat es richtig gemacht: Diese Dinge werden von oben getrieben. Wenn das Management nicht das Geld dafür ausgibt, Backups zu einer Priorität zu machen, haben die Sysadmins in der Regel Pech und tun mit den vorhandenen Ressourcen das Beste.

Der Schlüssel, wenn Sie einer dieser unglücklichen Admins sind - und ich war für einige Kundenengagements in diesem Boot -, ist, dass Sie sicherstellen, dass das Management wiederholt unterrichtet wird und dies auf papierähnliche Weise bestätigt wird ein Risiko für das Geschäft.

Meine Strategie ist es, ständig auf die Probleme einzuhämmern. Wenn Sie das tun, werden die Probleme manchmal behoben, aber es ist meistens so, dass sich derjenige, dem ich melde, nicht hinter der Ausrede "Ich wurde nie informiert" verstecken kann. Als Berater kann ich in der Regel eins besser machen. Ich kann meine Chefs dazu bringen, mehr leitende Angestellte zu informieren, als ich kann, dass eine Sicherheitslücke besteht. Dies verbreitet die Schuld oder konzentriert sie zumindest auf ein höheres Niveau als ich.

Gleichzeitig muss man erfinderisch sein und hart arbeiten, um die Risiken mit allen Ressourcen zu minimieren, die der Kunde bereitstellen kann.

In einigen Fällen können die Administratoren schuldhaft sein, aber das Management ist immer dafür verantwortlich, entweder das Risiko zu kennen und nicht genug zu tun, um es zu mindern, oder Leute einzustellen, die sie nicht auf diese Risiken aufmerksam machen.

Ich bin für ungefähr 200 Server im Nordwesten Großbritanniens verantwortlich, und dies ist offensichtlich viel zu viel, um es manuell zu überprüfen.

Ich konfiguriere die Sicherung so, dass nach Abschluss ein (VBScript-) Skript ausgeführt wird, das das Sicherungsprotokoll durchsucht, feststellt, ob die Sicherung funktioniert hat oder nicht, und einen Datensatz mit dem Sicherungsergebnis in eine zentrale Datenbank schreibt. Dann führe ich in der Zentrale ein Skript aus, das diese Datenbank abfragt und mir eine Liste von Sites anzeigt, bei denen entweder in der Sicherung ein Fehler gemeldet wurde oder es keinen Bericht von der Site gab.

Das Endergebnis ist, dass ich, wenn ich mich an meinen Schreibtisch setze, eine Liste aller Standorte habe, an denen ich die Sicherung überprüfen muss.

Der Sinn all dessen ist, dass die Standardannahme ist, dass die Sicherung fehlgeschlagen ist und die Sicherung nur dann funktioniert hat, wenn mein VBScript keine Fehler festgestellt und diese Schlussfolgerung in meine Datenbank geschrieben hat. Dies stellt sicher, dass Backup-Fehler nicht unbemerkt bleiben.

Einige der Server verwenden Backup Exec, andere NTBackup und andere kopieren ihre Dateien einfach auf einen anderen Server im Netzwerk. Es spielt keine Rolle, welche Art von Sicherung die Server ausführen, da es einfach ist, mein VBScript zu optimieren, um nach Fehlern zu suchen. Mein Skript ist eigentlich ziemlich einfach, es öffnet nur den Sicherungsbericht als Textdatei und sucht nach Begriffen wie "Fehler beim Laden", "Band voll", "CRC-Fehler" usw. Ich bin sicher, ein professioneller Programmierer würde das tun ein schlauer Job. Das Ganze ist jedoch einfach und robust, und es ist proaktiv in dem Sinne, dass ich den Backup-Fehlerbericht sehe, ob ich möchte oder nicht, und ich würde einen Fehler nur dann nicht bemerken, wenn ich mich bewusst entscheide, den Bericht zu ignorieren.

JR

PS 99% der Backup-Fehler sind darauf zurückzuführen, dass die Benutzer vergessen haben, das Backup-Band zu wechseln. Liebst du nicht nur Lusers :-)

Ein Backup, das nicht getestet wird, ist überhaupt kein Backup.