ISO9001, hier: Wöchentlicher Test auf Wiederherstellung?

[GMBauer]

Grüeziwoll beinand,

in unserer Firma kommen wir leider um eine ISO9001-Zertifizierung nicht mehr rum.

Nun möchte der Tester (TÜV Süd) ein Protokoll für einen wöchentlichen Test der Wiederhestellungsfähigkeit von VMs.

a) Ich lasse jede Woche ein Verify für alle VMs laufen, das ist belegt mit Screenshot oder z.B. der Live-Ansicht vom Longest Task im PBS. Backups laufen sowieso täglich.
b) Ich teste die Wiederherstellungsfähigkeit alle ein, zwei Monate mit einer Ubuntu-VM, auf der nur was niedrig priorisiertes läuft. Die wird halt unter einer anderen Nummer restored und gestartet, mehr nict.
c) Eine WinServer-VM mit einer Datenbank kann ich imho nicht testen auf Wiederherstellung, weil ich die Software dann entweder parallel zur "richtigen" Installation oder in einem Sandkasten starten müsste. Beides würde mir ggf. die Lizenzen abschießen.

Was meint ihr: Ist ein wöchentlicher Test auf Wiederherstellung nicht übertrieben? Wie testet Ihr VMs mit Nutz-Apps auf Wiederherstellung?

Sorry für bisschen OT (eigentlich gar nicht sooooo OT), aber ich wusste nicht, wo man das sonst fragen kann...

 

[jtru]

Was meint ihr: Ist ein wöchentlicher Test auf Wiederherstellung nicht übertrieben?

Ja klar ist es das, aber spielt das fuer die extrabuerokratische Extrabetuedelung des Auditors denn eine Rolle?

Wie testet Ihr VMs mit Nutz-Apps auf Wiederherstellung?

Ein Mal nach Inbetriebnahme, wenn es dazu einen konkreten Anlass gibt (= Applikation ist in irgendeiner Weise so besonders, dass die datenhaltenden Komponenten bzw. der funktionale Zustand der Anwendung nicht durch unsere gesammelte Expertise als "ist aller Wahrscheinlichkeit nach unkritisch zu restoren" beurteilt wird).

 

[Bu66as]

Hallo @GMBauer, ISO 9001 schreibt AFAIK kein festes Intervall für Restore-Tests vor. Ihr müsst in eurem Prozess festlegen, was wie oft getestet wird, und das begründen und dokumentieren. Wenn der Auditor "wöchentlich" will, würd ich nachfragen, wo das herkommt. Wöchentliches Verify plus z.B. monatlicher oder quartalsweiser echter Restore, risikobasiert, geht bei den Audits, die ich kenne, eigentlich gut durch.

Die DB-VM kannst du trotzdem testen. Leg dir eine Bridge ohne physischen Port an (z.B. vmbr99, keine bridge-ports), restore die VM mit neuer VMID und --unique und häng die NIC an diese Bridge oder setz link_down=1. Dann ist sie komplett isoliert, du startest sie und prüfst, ob Windows und der DB-Dienst hochkommen, und danach wird sie wieder gelöscht. Ob die Lizenz da mitspielt, hängt vom Hersteller ab. Viele erlauben DR-Tests ausdrücklich, das würd ich mir schriftlich geben lassen, dann hast du gleich was für den Auditor.

Das lässt sich gut skripten: qmrestore auf eine Test-ID, starten, per Guest-Agent prüfen ob die VM antwortet (qm agent <id> ping), Ergebnis mit Zeitstempel ins Log schreiben, qm destroy. Als Cronjob hast du dann jede Woche ein Protokoll und brauchst nicht mehr zu screenshotten.

 

[GMBauer]

Ich muss das irgendwie lösen. Der Vorbereitungs-Mensch hat der Chefin das ins Heft geschrieben.

Protokoll der wöchentlichen Wiederherstellungstests der VMs.

Wie gesagt, das war nur der Audit-Vorbereiter. Will das echt ein Prüfer sehen?

Ich habe hier Backups bis zum A*****, und ich teste absichtlich eine unkritische VM im Abstand von 1 bis 2 Monaten. Restoren, starten, läuft?, fertig.

Meinen bisherigen Erfahrungen nach ist es ja unkritisch, kurzzeitig eine zweite Windows-VM mit identischem Key zu starten, aber die Datev-Software kippt sofort die Lizenz, wenn die MAC-Adresse oder die IP oder sonstwas nicht stimmt. Dann heißt es in Nürnberg anrufen und für 60 Euro pro angefangener _Viertel_stunde die Lizenz zurückstellen lassen.

 

[GMBauer]

Die DB-VM kannst du trotzdem testen. Leg dir eine Bridge ohne physischen Port an (z.B. vmbr99, keine bridge-ports), restore die VM mit neuer VMID und --unique und häng die NIC an diese Bridge oder setz link_down=1. Dann ist sie komplett isoliert, du startest sie und prüfst, ob Windows und der DB-Dienst hochkommen, und danach wird sie wieder gelöscht.

Du meinst, nur einen Test, ob die VM hochfährt und keinen Test ob auf die DB von den Arbeitsplätzen aus zugegriffen werden kann? So vereinfacht hätte ich das nicht gesehen, das belegt ja eigentlich nur die Lauffähigkeit des Systems und nicht der "kompletten Anwendung". Um konkret zu sein, es geht um eine Sage Office Line 100, so ein ERP-Ding mit zwei untereinander kommunizierenden WinServer25-VMs, auf die von mehreren Arbeitsplätzen zugegriffen wird.

Aber wenn du sagst, dass es nur um die reine Lauffähigkeit, dann ist das ja simpel...

 

[Bu66as]

Was der Vorbereiter ins Heft schreibt, ist erstmal nur seine Empfehlung. Der Auditor prüft am Ende, ob ihr das macht, was in eurem eigenen Prozess festgelegt ist. Steht da z.B. "wöchentlich Verify + automatisierter Restore-/Boot-Test, quartalsweise Funktionstest der Anwendung" und du kannst das belegen, ist das eine saubere Sache. Würd ich so mit der Chefin abstimmen, bevor ihr euch auf wöchentlich Vollprogramm festnagelt.

Ja, der reine Boot-Test zeigt erstmal nur, dass das Backup konsistent ist und das System hochkommt. Für den Anwendungstest kannst du aber beide WinServer-VMs zusammen an die isolierte Bridge restoren, dann reden die mit ihren originalen IPs untereinander wie in Produktion. Wegen der Lizenzbindung (dein Datev-Beispiel mit MAC/IP) würd ich da dann ohne --unique restoren, dann bleiben die MACs gleich. Das geht aber nur, weil die Bridge keinen Uplink hat, sonst hast du doppelte MACs im Netz. Ob die Sage-Lizenzierung noch was anderes prüft oder nach Hause telefonieren will, weiß ich nicht, das würd ich beim Hersteller bzw. eurem Sage-Partner nachfragen. Für den Arbeitsplatz-Zugriff reicht dann eine Test-Client-VM an derselben Bridge: anmelden, Mandant öffnen, paar Belege aufrufen, Screenshot fürs Protokoll, VMs wieder weg.