Meinung Disaster Recovery Konzept

[IsThisThingOn]

Ich bin noch jung, da erlaube ich mir das mal

Ich würde halt einfach bei jedem Punkt darauf bestehen und klar machen, dass es total gegen deine Empfehlung ist.
Nein warte, ich würde ein komplettes Konzept vorzeigen mit neuer Hardware und wie ich es machen würde.
Wenn dann was nicht sauber läuft oder crashed, war es nicht deine Lösung die versagt hat. Das Konstrukt ist IMHO a disaster waiting to happen.

Bezüglich Netzwerk, das klingt IMHO auch sehr kompliziert, habe ich aber ehrlicherweise zu wenig Erfahrung.
DHCP nachtragen klingt irgendwie grauslig. Das klappt doch niemals sauber?

Proxy mit validen certs, auf den mittels DNS gezeigt wird, welcher dann wiederum zu einer ULA IPv6 proxed. Die ULA vereinfacht hier gleich mehrere Dinge, sie ist eindeutig, statisch, braucht kein DHCP und kann ganz einfach den Standort wechseln und die IPv6 mitnehmen.

 

[Supaman]

Ich würde halt einfach bei jedem Punkt darauf bestehen und klar machen, dass es total gegen deine Empfehlung ist.
Nein warte, ich würde ein komplettes Konzept vorzeigen mit neuer Hardware und wie ich es machen würde.
Wenn dann was nicht sauber läuft oder crashed, war es nicht deine Lösung die versagt hat. Das Konstrukt ist IMHO a disaster waiting to happen.

Prüfen ob das aktuelle Setup für die Zielsetzung geeignet ist. Technologie, WIssensstand und Anforderungen sind mitunter sehr dynamisch. Wenn man alles nach aktuellem Stand neu plant, findet man i.d.r. auch Punkte, die im alten Konzept übersehen wurden.

Es läuft nicht immer alles nach Plan - was kostet es, wenn die Recovery Zeit von 1 Stunde nicht eingehalten werden kann?
Was ist das maximale Zeitfenster bis es auf jeden Fall wieder laufen muss?
Daraus leitet sich dann auch das Budget für eine Modernisierung ab.

 

[rothkraut]

Proxy mit validen certs, auf den mittels DNS gezeigt wird, welcher dann wiederum zu einer ULA IPv6 proxed. Die ULA vereinfacht hier gleich mehrere Dinge, sie ist eindeutig, statisch, braucht kein DHCP und kann ganz einfach den Standort wechseln und die IPv6 mitnehmen.

Wenn IPv6 genutzt werden würde, wäre das ne Möglichkeit. Ist nicht der Fall. Aber gute Idee.

DHCP nachtragen klingt irgendwie grauslig. Das klappt doch niemals sauber?

Ist halt wie bei allem was manuell gepflegt werden muss. Da gibt's immer die Gefahr, das Fehler unterlaufen. Die Anzahl ist hier aber überschaubar. Es kommen in dem Cluster auch wirklich selten neuen VMs hinzu. Wenn man das sauber dokumentiert, ist es zwar ein nerviger Arbeitsschritt mehr, aber IMHO kein show-stopper.

Es gibt viele geile Konzepte und Ideen wie man solche Themen sauber umsetzen kann. Leider sieht es "im Feld" gerne mal anders aus. Ich kann diese beiden Standorte leider nicht "grüne-Wiese-mäßig" neu hoch ziehen. Hier muss ich damit arbeiten, was vorhanden ist.


Vielen lieben Dank erstmal an alle für den Input. Ich setze mich jetzt nochmal an ein etwas optimiertes Konzept und teste das dann mal durch.

 

[TJRFID]

Für die Datenbanken würde ich wirklich dringend empfehlen die native Replikation der Datenbanken zu nutzen, um das Zeitfenster eines Datenverlusts zu begrenzen und die Konsistenz der Datenbank zu gewährleisten.

 

[bl1mp]

Oder je nach Größe der DBs den nativen dump mittels PBS abziehen und syncen, aber stündlich kann das je nach Datenbank auch ein Performance Thema werden. Ohne DBJournal und/oder dump, kann auch deutlich mehr weg sein, als die letzte Stunde, weil die Datenbank darüber entscheidet wann die Blöcke auf die Disk geschrieben werden.

Virtuelle Backupserver halte ich persönlich für sehr ungünstig, weil man dort niemals/selten ein IAM Silo sauber umgesetzt bekommt und das ein großer Schwachpunkt bei Ransomware/Cybersecurity Thematiken ist/werden kann.

Alles andere ist aus der Ferne schwer abzuschätzen, weil man Annahmen über die Konnektivität und Hardwareausstattung und Betriebserfahrungen treffen muss.

BG, Lucas

 

[Bu66as]

Den Punkt mit dem virtuellen Backupserver würd ich mitnehmen, aber von anderer Seite: wenn der PBS als VM auf dem TrueNAS läuft und TrueNAS gleichzeitig die VM-Disks hält, hängen Produktivdaten und Backup am selben Blech. Für den Gebäude-weg-Fall egal, weil B eh die Kopie hat, aber für den deutlich wahrscheinlicheren "Storage zerlegt sich, Haus steht noch" ist das unschön. Wenn du die Sync-Richtung so drehst, dass der PBS in B pullt statt dass A pusht, und die Credentials auf A nur DatastoreBackup haben (kein Prune/Delete), ist das Ziel in B auch gegen einen kompromittierten Quellstandort halbwegs dicht. Kostet dich nichts extra und schwächt das IAM-Argument deutlich ab.

Zum DHCP: das funktioniert bei dir überhaupt nur, weil die MAC aus der Config mitkommt. Achte also drauf, dass dein Skript die .conf wirklich 1:1 rüberzieht und nirgends eine NIC neu angelegt wird, sonst zieht in B die falsche oder gar keine Reservierung und du suchst im Ernstfall unter Zeitdruck nach VMs ohne IP. Würd ich beim Testdurchlauf als erstes überprüfen.

 

[rothkraut]

Den Punkt mit dem virtuellen Backupserver würd ich mitnehmen, aber von anderer Seite: wenn der PBS als VM auf dem TrueNAS läuft und TrueNAS gleichzeitig die VM-Disks hält, hängen Produktivdaten und Backup am selben Blech. Für den Gebäude-weg-Fall egal, weil B eh die Kopie hat, aber für den deutlich wahrscheinlicheren "Storage zerlegt sich, Haus steht noch" ist das unschön

Diese TrueNAS wird, auch jetzt schon, zusätzlich noch auf eine weitere TrueNAS am gleichen Standort synchronisiert. Habe ich leider versäumt zu erwähnen.

Wenn du die Sync-Richtung so drehst, dass der PBS in B pullt statt dass A pusht, und die Credentials auf A nur DatastoreBackup haben (kein Prune/Delete), ist das Ziel in B auch gegen einen kompromittierten Quellstandort halbwegs dicht. Kostet dich nichts extra und schwächt das IAM-Argument deutlich ab.

Vielen Dank für diesen Hinweis!

 

[bl1mp]

Der Punkt mit dem Pull-Sync ist so definitiv wertvoll.
Je nach Umgebung würde ich prüfen, wie das Adminkonzept für den PBS ist.
Theoretisch gehört da eine dedizierte Adminworkstation dazu.

Damit die letzte Bastion nicht von den gleichen Kiste aus betreut werden,
mit der die Admins auch den Storage betreuen, oder ihre Emails lesen.
Denn auch die werden im Zweifelsfall betroffen sein.

Das ist ggf. allerdings auch eine Frage des akzeptieren Restrisikos.

BG, Lucas