Skip to content

Heiliger manitu

(aus dem Support)
(...) Ich hätte Priester werden sollen. Also bete ich mal... (...) Diese Daten brauch ich auf jeden Fall (...) sonst bin ich ein Kopf kürzer. Kleine Bitte an den heiligen Manitu (...)
Die Daten gab's natürlich bereits gestern Abend.

Kommentare

Ansicht der Kommentare: Linear | Verschachtelt

DeserTStorM

"... und der heilige Manitu hat dich erhört..." :rofl:

nighthawk

Na eigentlich haben Menschen, die keine Sicherheitskopien anfertigen, es aber verdient den Kopf (sprichwörtlich!) abzubekommen... Denn so lernen sie es ja doch nicht.

Der kopflose Reiter?

Hab ich's in den Blog geschafft? Auch gut. :)
Noch'n bißchen Vorurteile glätten...

Nun, es gibt immer was zu Lernen. Es gab ja Backups. Wenn dir dann allerdings auch die Backupmaschine entgleitet, bleibt noch der zusätzliche Storage zur Rekonstruktion. Es ging um Bestätigung der modifizierten _Zugangs_daten zu den Sicherheitskopien im RZ :) Auch weitere Offline-Sicherheitskopien waren vorhanden, aber via remote nicht so zeitnah einspielbar. Das Beten stand für Wunsch nach Geschwindigkeit und für den flinken Erhalt der Zugangsdaten, um aktuelle Sicherungen aus dem Storage verwenden zu können. Natürlich mit der Hoffnung, dass wenigstens dort noch die Welt in Ordnung ist und nicht noch ein weiteres Netz reißt.

Ganze Systeme zu backupen und zu restoren geht ja schnell ist aber teilweise unsinnig, z.B. wenn sie komprommitiert wurden und der genaue Zeitpunkt und die Schwachstelle noch nicht in so kurzer Zeit analysiert werden konnte. Dann würdeste dir den ganzen Quark wieder zurückspielen, nur um ein System schnell wieder am Start zu haben und hättest in Kürze das gleiche Problem.

Es ging hier um den Zugang zu reinen Nutzdaten und Backups derselben. Und auch ein Stückeln à la "Snapshop eines älteres, nachweislich cleanen System restoren Updates und Patches fahren und aktuellste Nutzdaten restoren," ist nicht immer sinnvoll. z.B. wenn nicht direkt nachvollziehbar ist, wo das Leck liegt und ob Hard- oder Softwarefehler Ursache sind. Mal ganz abgesehen von den evtl. entstehenden Inkompatibilitäten und dem Mehraufwand. Neues System, Restore der Konfiguration und Nutzdaten ist da häufig sinnvoller.

Oder lieg ich falsch? :)

bla

Also bitte jetz ma nich übertreiben :P

Der kopflose Reiter?

übertreiben? womit? Stand der Dinge. Zwei Server (Redundanz Master- und Slavesystem) und ein zusätzliche Storage-Einheit vorhanden. Beide Server (trotz leicht unterschiedlicher System-Zugangsdaten) komprommitiert. Jeder trug zugleich noch Backupdaten des anderen und SQL Replikation. Tja. Kommt vor. Und was machste? Willst ja Spuren erhalten und analysieren, aber zugleich Dienste schnell wieder an den Start bringen. Also neue Maschine dazu, Dienste neu aufsetzen und Zugang zum Storage um die aktuellen Daten und Konfigurationen zurückzuholen. Mit Prüfung der Daten. Genau darum gings. Oder hätt's da ne bessere Lösung gegeben? Bin ganz Ohr :)

Kommentar schreiben

Umschließende Sterne heben ein Wort hervor (*wort*), per _wort_ kann ein Wort unterstrichen werden.
Standard-Text Smilies wie :-) und ;-) werden zu Bildern konvertiert.
Die angegebene E-Mail-Adresse wird nicht dargestellt, sondern nur für eventuelle Benachrichtigungen verwendet.

Um maschinelle und automatische Übertragung von Spamkommentaren zu verhindern, bitte die Zeichenfolge im dargestellten Bild in der Eingabemaske eintragen. Nur wenn die Zeichenfolge richtig eingegeben wurde, kann der Kommentar angenommen werden. Bitte beachten Sie, dass Ihr Browser Cookies unterstützen muss, um dieses Verfahren anzuwenden.
CAPTCHA

BBCode-Formatierung erlaubt
Formular-Optionen