21
SQL Restore ohne jeglichen Verlust möglich?
Hallo zusammen,
wir prüfen gerade die Anforderungen eines noch einzuführenden automatischen Lagers.
Das System speichert dabei alle Zustände in einer zentralen MS-SQL Datenbank.
Nun stolpern wir über den Fall eines eventuellen Restores z.b. nach Ransomware-Angriff.
Sollte dabei der Zustand des Lagers von der SQL DB abweichen, so könnte dies auf eine neue Inventarisierung und einen mehrmonatigen Ausfall hinauslaufen.
Zur Frage:
Kennt jemand Techniken, die DB „verlustfrei“ zu: duplizieren, backupen, spiegeln, exportieren, … ?
Es geht hier explizit nur um den Restore-Fall und nicht um die Verfügbarkeit.
Danke und Gruß
wir prüfen gerade die Anforderungen eines noch einzuführenden automatischen Lagers.
Das System speichert dabei alle Zustände in einer zentralen MS-SQL Datenbank.
Nun stolpern wir über den Fall eines eventuellen Restores z.b. nach Ransomware-Angriff.
Sollte dabei der Zustand des Lagers von der SQL DB abweichen, so könnte dies auf eine neue Inventarisierung und einen mehrmonatigen Ausfall hinauslaufen.
Zur Frage:
Kennt jemand Techniken, die DB „verlustfrei“ zu: duplizieren, backupen, spiegeln, exportieren, … ?
Es geht hier explizit nur um den Restore-Fall und nicht um die Verfügbarkeit.
Danke und Gruß
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 669264
Url: https://administrator.de/contentid/669264
Ausgedruckt am: 03.12.2024 um 17:12 Uhr
21 Kommentare
Neuester Kommentar
Hi,
so allein geht das nicht! Stichwort Moment-Aufnahme!
Einmal am Tag - sollte klar sein - fehlen etliche Datensätze. Problem ist aber doch allg. auch ein Stromausfall. Wo liegt die Intelligenz? Wenn Aktionen nicht sauber zurückgerollt werden verbleiben Fragmente die ggf. die Software negativ beeinflussen. Solche Anomalien wirkt in erster Linie der Sofware Entwickler entgegen. Hier geht es also z.B. darum was passiert, wenn dem SQL Server der Boden untern F´üßen wegbricht: hartes ausschalten, Stromausfall etc.
Restrisiko bleibt. Wenn müsste es wie bei manchen BDE- oder Zeiterfassugnsterminals laufen: Daten werden zwischengespeichert und können später gelesen werden. Zeitstempelungen bleiben im Terminal bis sie abgeholt wurden.
Extra VLAN und entsprechende Softwar scihern zusätzlich. Datenbankspiegelung und Hochverfügbarkeit geben auch etwas Sicherheit. Sofern die Standorte korrekt abgesichert sind.
Restore Frage ist zu "billig". Wenn das ganze so empfindlich ist braucht es ein Gesamtkonzept. Ggf. Test-Umgebung und 1, 2 Szenarien anzutesten.
Das Lager ist ja noch nicht da! Frag gezielt nach, wie die Dinger auch autark kurzzeitig arbeiten oder hab es dann einen globalen Stop aller Aktionen gibt, so dass die Datenbestände nicht auseinanderlaufen. Meist gibt es doch auch Leitrechner direkt an den Maschinen und Roll-/ Röllchenbahnen.
Manche Hersteller nehmen gern Procedures aus dem SQL umd in Milisekunden Entscheidungen zu treffen. Dann wäre aber immer eine Kommunikation nötig! Die Anlagen selber haben ja SPS. Das macht ja alles der Hersteller.
Meiner Meinung nach kann auch nur der Hersteller dir Empfehlungen geben wie man nach Totalausfall alles wieder hoch fährt. Makierungen? Neu einlesen der Barcodes via Roboter?
Die bekommen doch eh einen Haufen Geld. Würde da nun klären wer für was zuständig ist und wie man einen "Kaltstart" überlebt. Keine Ahnung: Trennung in Sektionen. Schritt für Schritt in Betrieb nehmen? Ggf. manuell nur das auf den Bahen zählen, oder gar automatisch. Ggf. das als "Abfall" abführen und von Hand zählen. Später Lager wieder zuführen und Bestände kontrollieren?
Wenn ihr mit Schwellwerten arbeitet kann man entsprechend das Ganze abpuffern. Irrläufer später einfangen und erneut zuführen. Dafür kenenn wir Euer Produkt nicht!
Aber es ist schon OK sich Gedanken zu machen. Nachabr zur Firma wo ich Arbeite stellen Leuchtmittel her. Hochregallager - ka 20m oder mehr. Da ruhte Anfang des Jahres alles für Wochen - Schadsoftware....
Es gibt sicherlich Methoden das Ganze so aufzuteilen dass eine manuelle Nachberetiung möglich wenn nötig macht. Aber dazu müsste man die Gesamtsituation kennen!
Feuer, Stromausfall > mehrere Std. - all das ist real! Kann ja aber nur sauber aufgelöst werden, wenn man neben Vollautomaischen Betireb auch manuellen Overwrite vorsieht. Bzw. es nacharbeiten kann. Sonst bleib nur verbrannte Erde und man fängt bei Null an!
so allein geht das nicht! Stichwort Moment-Aufnahme!
Einmal am Tag - sollte klar sein - fehlen etliche Datensätze. Problem ist aber doch allg. auch ein Stromausfall. Wo liegt die Intelligenz? Wenn Aktionen nicht sauber zurückgerollt werden verbleiben Fragmente die ggf. die Software negativ beeinflussen. Solche Anomalien wirkt in erster Linie der Sofware Entwickler entgegen. Hier geht es also z.B. darum was passiert, wenn dem SQL Server der Boden untern F´üßen wegbricht: hartes ausschalten, Stromausfall etc.
Restrisiko bleibt. Wenn müsste es wie bei manchen BDE- oder Zeiterfassugnsterminals laufen: Daten werden zwischengespeichert und können später gelesen werden. Zeitstempelungen bleiben im Terminal bis sie abgeholt wurden.
Extra VLAN und entsprechende Softwar scihern zusätzlich. Datenbankspiegelung und Hochverfügbarkeit geben auch etwas Sicherheit. Sofern die Standorte korrekt abgesichert sind.
Restore Frage ist zu "billig". Wenn das ganze so empfindlich ist braucht es ein Gesamtkonzept. Ggf. Test-Umgebung und 1, 2 Szenarien anzutesten.
Das Lager ist ja noch nicht da! Frag gezielt nach, wie die Dinger auch autark kurzzeitig arbeiten oder hab es dann einen globalen Stop aller Aktionen gibt, so dass die Datenbestände nicht auseinanderlaufen. Meist gibt es doch auch Leitrechner direkt an den Maschinen und Roll-/ Röllchenbahnen.
Manche Hersteller nehmen gern Procedures aus dem SQL umd in Milisekunden Entscheidungen zu treffen. Dann wäre aber immer eine Kommunikation nötig! Die Anlagen selber haben ja SPS. Das macht ja alles der Hersteller.
Meiner Meinung nach kann auch nur der Hersteller dir Empfehlungen geben wie man nach Totalausfall alles wieder hoch fährt. Makierungen? Neu einlesen der Barcodes via Roboter?
Die bekommen doch eh einen Haufen Geld. Würde da nun klären wer für was zuständig ist und wie man einen "Kaltstart" überlebt. Keine Ahnung: Trennung in Sektionen. Schritt für Schritt in Betrieb nehmen? Ggf. manuell nur das auf den Bahen zählen, oder gar automatisch. Ggf. das als "Abfall" abführen und von Hand zählen. Später Lager wieder zuführen und Bestände kontrollieren?
Wenn ihr mit Schwellwerten arbeitet kann man entsprechend das Ganze abpuffern. Irrläufer später einfangen und erneut zuführen. Dafür kenenn wir Euer Produkt nicht!
Aber es ist schon OK sich Gedanken zu machen. Nachabr zur Firma wo ich Arbeite stellen Leuchtmittel her. Hochregallager - ka 20m oder mehr. Da ruhte Anfang des Jahres alles für Wochen - Schadsoftware....
Es gibt sicherlich Methoden das Ganze so aufzuteilen dass eine manuelle Nachberetiung möglich wenn nötig macht. Aber dazu müsste man die Gesamtsituation kennen!
Feuer, Stromausfall > mehrere Std. - all das ist real! Kann ja aber nur sauber aufgelöst werden, wenn man neben Vollautomaischen Betireb auch manuellen Overwrite vorsieht. Bzw. es nacharbeiten kann. Sonst bleib nur verbrannte Erde und man fängt bei Null an!
Hi,
alles eine Frage des Geldes. Kontinuierliche Datensicherung (z.B. mit Veeam) kombiniert mit Transaktionen und du hast geringstmögliche Datenverluste.
Gruß,
Thomas
alles eine Frage des Geldes. Kontinuierliche Datensicherung (z.B. mit Veeam) kombiniert mit Transaktionen und du hast geringstmögliche Datenverluste.
Gruß,
Thomas
Hallo und Danke für den Input.
ein Ausfall der DB fällt unter den Punkt Verfügbarkeit. Läuft die DB nicht, steht auch das System. Dies ist nicht gut, aber ein überschaubares Risiko und lässt sich berechnen.
Natürlich gibt es ein VM Cluster, HA Storage, VLAN Trennung, ...etc.
Hilft aber alles nichts, wenn man trotzdem mal zum Backup greifen muss. Und über diesen Fall machen wir uns hier im vorhinein Gedanken.
Das System selber speichert nichts intern, sondern wirklich alles in der SQL DB.
Geld spielt keine Rolle. Doch, bestimmt. Aber dies fällt mit ins Projekt. Wer A sagt muss auch B sagen.
Veeam ist in der Tat im Einsatz und CDP steht schon auf der Liste.
Danke
ein Ausfall der DB fällt unter den Punkt Verfügbarkeit. Läuft die DB nicht, steht auch das System. Dies ist nicht gut, aber ein überschaubares Risiko und lässt sich berechnen.
Natürlich gibt es ein VM Cluster, HA Storage, VLAN Trennung, ...etc.
Hilft aber alles nichts, wenn man trotzdem mal zum Backup greifen muss. Und über diesen Fall machen wir uns hier im vorhinein Gedanken.
Das System selber speichert nichts intern, sondern wirklich alles in der SQL DB.
Geld spielt keine Rolle. Doch, bestimmt. Aber dies fällt mit ins Projekt. Wer A sagt muss auch B sagen.
Veeam ist in der Tat im Einsatz und CDP steht schon auf der Liste.
Danke
https://learn.microsoft.com/de-de/azure/azure-sql/database/business-cont ...
Ist zwar Azure. Würde mir mal die Modelle dort mit anschauen. Protokollversand etc. wird auch mit angesprochen.
Hab es leider noch nicht eingesetzt. Aber eigentlich sind die MS Dokus recht gut. Ggf. erhälst du dort nochmal Input, bzw. wie man es auch on-premise so ähnlich durchführen kann.
Auch ein geringer Datenverlust kann eine komplette Zählung nach sich ziehen, wenn durch falsche Werte in den "Leitdateien" alles durcheinander gerät. Da ist die Frage was darf ausfallen und ist ohne großen manuellen Aufwand wiederherstellbar. Jetzt nicht auf Restore bezogen. Sondern auf das etwaige nacharbeiten.
Entweder du findest hier einen Crack/ SQL Guru oder du solltest es ggf. in einen Systemhaus/ Freelancer "einkaufen". Beratung, vorab Labor-Test..... Gibt ja einige die nix anderes machen
Ich denke mal nicht das SQL Agent von Acronis o.ä. hier reichen wird. Und vieles bringen die Server ja schon mit.
Ist zwar Azure. Würde mir mal die Modelle dort mit anschauen. Protokollversand etc. wird auch mit angesprochen.
Hab es leider noch nicht eingesetzt. Aber eigentlich sind die MS Dokus recht gut. Ggf. erhälst du dort nochmal Input, bzw. wie man es auch on-premise so ähnlich durchführen kann.
Auch ein geringer Datenverlust kann eine komplette Zählung nach sich ziehen, wenn durch falsche Werte in den "Leitdateien" alles durcheinander gerät. Da ist die Frage was darf ausfallen und ist ohne großen manuellen Aufwand wiederherstellbar. Jetzt nicht auf Restore bezogen. Sondern auf das etwaige nacharbeiten.
Entweder du findest hier einen Crack/ SQL Guru oder du solltest es ggf. in einen Systemhaus/ Freelancer "einkaufen". Beratung, vorab Labor-Test..... Gibt ja einige die nix anderes machen
Ich denke mal nicht das SQL Agent von Acronis o.ä. hier reichen wird. Und vieles bringen die Server ja schon mit.
Hi, ein Drucker, der grobe Eckdaten: Datum, Artikel, Fach, Menge im Zuge der Transaktion druckt. Im Restore fall, kannst du dann nur die Fächer seit dem Backup inventarisieren.
Habe keine sinnvolle Erfahrung beizusteuern, aber bei uns kommt auch langsam das Thema auf, dass gerade bei einer DB ein Backup nicht immer die sichere Rettung ist.
Gerade bei Ransomware müsstest du den exakten Zeitpunkt und ev. sogar alle falschen Änderungen herausfinden können. (Ist ransomware schon so weit, dass sie DBs gezielt sabotiert?)
Habe keine sinnvolle Erfahrung beizusteuern, aber bei uns kommt auch langsam das Thema auf, dass gerade bei einer DB ein Backup nicht immer die sichere Rettung ist.
Gerade bei Ransomware müsstest du den exakten Zeitpunkt und ev. sogar alle falschen Änderungen herausfinden können. (Ist ransomware schon so weit, dass sie DBs gezielt sabotiert?)
Mahlzeit,
wie schon angesprochen, sichere die Transaktion Logs in kurzen Zeit Intervallen und setzte CDP (Continuous Data Protection) ein. Damit bist Du im Falle einer Wiederherstellung (Restore) gut abgesichert.
100%ige Sicherheit wirst Du / werdet Ihr niemals erreichen. Weil, das ist unbezahlbar. Diese Summe der Finanzmittel habt ihr nicht.
Gruss Penny.
wie schon angesprochen, sichere die Transaktion Logs in kurzen Zeit Intervallen und setzte CDP (Continuous Data Protection) ein. Damit bist Du im Falle einer Wiederherstellung (Restore) gut abgesichert.
100%ige Sicherheit wirst Du / werdet Ihr niemals erreichen. Weil, das ist unbezahlbar. Diese Summe der Finanzmittel habt ihr nicht.
Gruss Penny.
Guten Tag,
die Problematik ergibt sich nicht aus deiner Fragestellung.
Denn ein verlustfreies duplizieren ist kaum ein großer Sprung. Der Große Sprung ist, die Verlustfreie duplizierung so zu gestalten, dass keine maliziösen Informationen dupliziert werden.
Grundsätzlich ist daher ein mehrstufiges Sicherungs und vor allem Absicherungssystem von nöten.
Wie das ganze gestaltet werden kann und wie dies insbesondere bei euch auf zu setzen ist, hängt vor allem von einem Faktor ab, auf den wir keinen Einblick haben: Software und Methodik der automatischen Lagers.
-> Was passiert, wenn es "keine DB" mehr gibt? -> Stop?
-> Wird geprüft, ob die DB konsistent ist? -> Wenn nicht Stop?
-> Wie sichert Ihr euch allgemein ab? (Auf jeglicher Ebene).
Das kann man aber nicht mehr im Forum abklopfen. Nur allgemein und das wird euch nicht helfen.
die Problematik ergibt sich nicht aus deiner Fragestellung.
Denn ein verlustfreies duplizieren ist kaum ein großer Sprung. Der Große Sprung ist, die Verlustfreie duplizierung so zu gestalten, dass keine maliziösen Informationen dupliziert werden.
Grundsätzlich ist daher ein mehrstufiges Sicherungs und vor allem Absicherungssystem von nöten.
Wie das ganze gestaltet werden kann und wie dies insbesondere bei euch auf zu setzen ist, hängt vor allem von einem Faktor ab, auf den wir keinen Einblick haben: Software und Methodik der automatischen Lagers.
-> Was passiert, wenn es "keine DB" mehr gibt? -> Stop?
-> Wird geprüft, ob die DB konsistent ist? -> Wenn nicht Stop?
-> Wie sichert Ihr euch allgemein ab? (Auf jeglicher Ebene).
Das kann man aber nicht mehr im Forum abklopfen. Nur allgemein und das wird euch nicht helfen.
Hallo,
also am ehesten würden mir die Transaktionslogs einfallen. Darüber kann man glaub ich auch replizieren.
aber 100% ist das auch nicht.
Wenn z.b. jemand auf deine Datenbank kommt und absichtlich falsche Buchungen erzeugt, bist du auch wieder am A*
Das hier noch auf diversen anderen Ebenen gesichert werden muss ich aber glaub ich nicht erwähnen
also am ehesten würden mir die Transaktionslogs einfallen. Darüber kann man glaub ich auch replizieren.
aber 100% ist das auch nicht.
Wenn z.b. jemand auf deine Datenbank kommt und absichtlich falsche Buchungen erzeugt, bist du auch wieder am A*
Das hier noch auf diversen anderen Ebenen gesichert werden muss ich aber glaub ich nicht erwähnen
Moin,
das Meiste wurde ja schon gesagt.
Es wird noch eine Spur komplexer wenn man externe Anbindungen mit EDI hat.
Das können z.B: Kunden, Lieferanten, Buchhaltung, Warenwirtschaft, Logistikanbieter, etc sein.
Dann muss ein neues Anfahren des System nicht nur alle interne Abläufe mitnehmen sondern auch alle externen. Sonst kommst Du zur nächsten Katastrophe.
Stefan
das Meiste wurde ja schon gesagt.
Es wird noch eine Spur komplexer wenn man externe Anbindungen mit EDI hat.
Das können z.B: Kunden, Lieferanten, Buchhaltung, Warenwirtschaft, Logistikanbieter, etc sein.
Dann muss ein neues Anfahren des System nicht nur alle interne Abläufe mitnehmen sondern auch alle externen. Sonst kommst Du zur nächsten Katastrophe.
Stefan
1Zitat von @StefanKittel:
Moin,
das Meiste wurde ja schon gesagt.
Es wird noch eine Spur komplexer wenn man externe Anbindungen mit EDI hat.
Moin,
das Meiste wurde ja schon gesagt.
Es wird noch eine Spur komplexer wenn man externe Anbindungen mit EDI hat.
OH ja... Lobster.... Kann zwar auch wiederholen aber auch nicht immer. Je nach Art wie die Phase 6 aufgebaut wird.
Hängt ja auch immer mit den Schnittstellen zusammen. wenn die nur funktionieren, wenn der Datensatz integer ist, sollte es passen. Entweder geht oder nicht. Damit hat man zumindest eine Grundlage um alles liegen gebliebende wieder reinzukippen.
Aber du hast schon recht: kann ekelhaft werden. Wenn man einen hat der SQL, PowerShell und die Business-Prozesse versteht kann man sich rasch Helferlein schreiben und so das Problem eindampfen. Ansonsten wird es je nach Umfang sehr komplex.
Diese Frage sollte man sich auch stellen. Sicherheit beginnt mit der Überlegung: Wie funktioniert der Angriffsvektor? Gegen was schütze ich mich womit?
Ransomware ist nach meinem Wissen ~99% Verschlüsselung lokaler Dateien, OS und Netzlaufwerke. Normalerweise kommt das nicht so schnell auf einen Server, das sollte man auch abschotten. Wenn es doch den OS Unterbau trifft dann wäre natürlich auch ein Sicherungssystem gefährdet.
Ransomware ist nach meinem Wissen ~99% Verschlüsselung lokaler Dateien, OS und Netzlaufwerke. Normalerweise kommt das nicht so schnell auf einen Server, das sollte man auch abschotten. Wenn es doch den OS Unterbau trifft dann wäre natürlich auch ein Sicherungssystem gefährdet.
Zitat von @ukulele-7:
Diese Frage sollte man sich auch stellen. Sicherheit beginnt mit der Überlegung: Wie funktioniert der Angriffsvektor? Gegen was schütze ich mich womit?
Ransomware ist nach meinem Wissen ~99% Verschlüsselung lokaler Dateien, OS und Netzlaufwerke. Normalerweise kommt das nicht so schnell auf einen Server, das sollte man auch abschotten. Wenn es doch den OS Unterbau trifft dann wäre natürlich auch ein Sicherungssystem gefährdet.
Diese Frage sollte man sich auch stellen. Sicherheit beginnt mit der Überlegung: Wie funktioniert der Angriffsvektor? Gegen was schütze ich mich womit?
Ransomware ist nach meinem Wissen ~99% Verschlüsselung lokaler Dateien, OS und Netzlaufwerke. Normalerweise kommt das nicht so schnell auf einen Server, das sollte man auch abschotten. Wenn es doch den OS Unterbau trifft dann wäre natürlich auch ein Sicherungssystem gefährdet.
Ja, aber Ransomware ist ja nur eine Bedrohung.
Dazu kommen Dinge wie Sabotage von Innen, Softwarefehler, Benutzerfehler, etc.
Irgendwas ist doch immer waran im Vorfeld keiner Gedacht hat.
Also geht man vom Worst-Case-Szenario aus.
Alles kaputt und alles doof zusammen mit Datenverlust.
Stefan
Moin,
100% kannst du nicht abfrühstücken - wie oben schon erwähnt.
Stromausfall ist ja das eine - kein Strom, kein LVS (Lagerverwaltungssystem) und in Folge dessen auch keine weiteren Lagerbewegungen.
Wenn aber eure DB (über mehrere Wochen) sukzessive manipuliert wurde oder die Schadsoftware schon mehrere Wochen im System war und nur schlummerte, musst du ja auch die DaSi bemühen und den Server neu aufsetzen. Hierbei könnte man noch überlegen, die Nutzdaten (mdb, ldf) aus dem kompromittierten Server zu extrahieren und in den neuen Server einzuspielen - ob ihr da nicht aber dennoch nicht mehr integre Daten habt, muss dann geprüft werden.
Muss dazu jedes Gut aus dem Fach entnommen und durch einen Mitarbeiter geprüft und neu erfasst werden?
Ein gutes LVS sollte ja mittels NFC/ Barcodes seine Produkte selbst scannen können - das arbeitet auch dann, wenn kein MA da ist - theoretisch
Wie führt ihr eigentlich die gesetzlich vorgeschriebene Inventur durch. Hier müsst ihr ja auch prüfen, ob das, was im System steht, im Lager liegt. Gut, das geht ja auch Unterjährig im Rahmen einer permanenten Inventur.
Worauf ich hier hinaus will: eine Vollinventur wäre die sauberste Variante. Wenn die binnen weniger Stunden/ Tage durchführbar ist, wäre es ja pfiffig, im DR-Fall die DB des LVS mit als erstes an rennen zu bringen. Dann kann das LVS loslegen und ihr könnt weitere Dienste wie Mail-Server, File-Server, ERP, div. Applikationen, ... recovern. Wenn dann das LVS durch ist, wären u. U. auch die anderen Systeme einsatzbereit.
Wie sehen eigentlich eure Kennzahlen für die RTO und RPO aus?
https://www.novabackup.de/blog/kpis-zur-bewertung-datensicherung
oder sind die für das LVS schon mit 0 Sekunden definiert worden?
100% kannst du nicht abfrühstücken - wie oben schon erwähnt.
Stromausfall ist ja das eine - kein Strom, kein LVS (Lagerverwaltungssystem) und in Folge dessen auch keine weiteren Lagerbewegungen.
Wenn aber eure DB (über mehrere Wochen) sukzessive manipuliert wurde oder die Schadsoftware schon mehrere Wochen im System war und nur schlummerte, musst du ja auch die DaSi bemühen und den Server neu aufsetzen. Hierbei könnte man noch überlegen, die Nutzdaten (mdb, ldf) aus dem kompromittierten Server zu extrahieren und in den neuen Server einzuspielen - ob ihr da nicht aber dennoch nicht mehr integre Daten habt, muss dann geprüft werden.
neue Inventarisierung und einen mehrmonatigen Ausfall hinauslaufen.
Für eine Vollinventur braucht ihr tatsächlich mehrere Monate?Muss dazu jedes Gut aus dem Fach entnommen und durch einen Mitarbeiter geprüft und neu erfasst werden?
Ein gutes LVS sollte ja mittels NFC/ Barcodes seine Produkte selbst scannen können - das arbeitet auch dann, wenn kein MA da ist - theoretisch
Wie führt ihr eigentlich die gesetzlich vorgeschriebene Inventur durch. Hier müsst ihr ja auch prüfen, ob das, was im System steht, im Lager liegt. Gut, das geht ja auch Unterjährig im Rahmen einer permanenten Inventur.
Worauf ich hier hinaus will: eine Vollinventur wäre die sauberste Variante. Wenn die binnen weniger Stunden/ Tage durchführbar ist, wäre es ja pfiffig, im DR-Fall die DB des LVS mit als erstes an rennen zu bringen. Dann kann das LVS loslegen und ihr könnt weitere Dienste wie Mail-Server, File-Server, ERP, div. Applikationen, ... recovern. Wenn dann das LVS durch ist, wären u. U. auch die anderen Systeme einsatzbereit.
Wie sehen eigentlich eure Kennzahlen für die RTO und RPO aus?
https://www.novabackup.de/blog/kpis-zur-bewertung-datensicherung
oder sind die für das LVS schon mit 0 Sekunden definiert worden?
Also die "gewöhnliche" Datensicherung, sagen wir alle 24h Nachts, deckt ja schonmal viele Schades-Szenarien ab und ist vergleichsweise günstig. Du kannst hier die üblichen Wege gehen und z.B. zusätzlich auf Band sichern und das Band physisch schützen oder du kannst dir Dinge wie immutable backup repository anschauen.
Ich kann natürlich sagen ich betrachte kein konkretes Schadens-Szenario, sondern möchte einen guten Allgemein-Schutz, den habe ich dann Backup-Seitig. Wenn ich dann natürlich daher gehe und anfange mit "wenn aber", dann halte ich dem wieder ein konkretes Szenario entgegen, welches nicht (ausreichend) damit abgedeckt wird - dann drehe ich mich argumentativ schnell im Kreis Es gibt nicht eine Strategie, die gegen alles gut schützt.
Am Ende wird man auch in diesem Fall eher abwägen. Konzepte wie CDP hören sich gut an, kosten aber auch viel. Wir haben z.B. eine aktiv-passiv Spiegelung auf Block Storage Ebene. Ist sicherlich gut gegen Hardware Schäden, Feuer, Wasser, etc. sollte laufen. Gegen eine Ransomware hilft das nicht, die kann ich gar nicht filtern. Ich kann höchstens ihre Aktivität erkennen und den Zugriff unterbinden, dann ist aber ungünstigerweise eventuell auch schon ein Schaden eingetreten.
Ich habe sowas noch nicht umgesetzt aber du kannst vielleicht alle Vorgänge in einem WORM System loggen, aus solchen Logs kann man mit den passenden SQL Befehlen auch wieder Vorgänge rückabwickeln. Solche Logs kann man notfalls sichten und dann bestimmen, was das Rollback macht. Angenommen, es werden wirklich Daten innerhalb der DB manipuliert, nicht nur die DB als ganzes, dann kann dir das theoretisch helfen, den Schaden komplett zu erfassen und zu beheben. Aber: Wozu der ganze Aufwand eigentlich? Da ist eine automatische Inventur durch das Lagersystem selbst doch viel eleganter und vermutlich schneller.
Ich kann natürlich sagen ich betrachte kein konkretes Schadens-Szenario, sondern möchte einen guten Allgemein-Schutz, den habe ich dann Backup-Seitig. Wenn ich dann natürlich daher gehe und anfange mit "wenn aber", dann halte ich dem wieder ein konkretes Szenario entgegen, welches nicht (ausreichend) damit abgedeckt wird - dann drehe ich mich argumentativ schnell im Kreis
Es gibt nicht eine Strategie, die gegen alles gut schützt.Am Ende wird man auch in diesem Fall eher abwägen. Konzepte wie CDP hören sich gut an, kosten aber auch viel. Wir haben z.B. eine aktiv-passiv Spiegelung auf Block Storage Ebene. Ist sicherlich gut gegen Hardware Schäden, Feuer, Wasser, etc. sollte laufen. Gegen eine Ransomware hilft das nicht, die kann ich gar nicht filtern. Ich kann höchstens ihre Aktivität erkennen und den Zugriff unterbinden, dann ist aber ungünstigerweise eventuell auch schon ein Schaden eingetreten.
Ich habe sowas noch nicht umgesetzt aber du kannst vielleicht alle Vorgänge in einem WORM System loggen, aus solchen Logs kann man mit den passenden SQL Befehlen auch wieder Vorgänge rückabwickeln. Solche Logs kann man notfalls sichten und dann bestimmen, was das Rollback macht. Angenommen, es werden wirklich Daten innerhalb der DB manipuliert, nicht nur die DB als ganzes, dann kann dir das theoretisch helfen, den Schaden komplett zu erfassen und zu beheben. Aber: Wozu der ganze Aufwand eigentlich? Da ist eine automatische Inventur durch das Lagersystem selbst doch viel eleganter und vermutlich schneller.
Exkurs:
Einige Storage-Hersteller (u. a. IBM) haben KI-Technologien implementiert, die Ransomware-Aktivitäten auf Blockebene erkennen können. In Kombination mit den Immutable Copies der Blöcke ein guter Schutz (aber auch keine 100%).
Hier beschreibt IBM das ganz gut: https://www.ibm.com/support/pages/system/files/inline-files/2024%20Accel ...
Gegen eine Ransomware hilft das nicht, die kann ich gar nicht filtern. Ich kann höchstens ihre Aktivität erkennen und den Zugriff unterbinden, dann ist aber ungünstigerweise eventuell auch schon ein Schaden eingetreten.
Mit passenden Storage-Lösungen kann man aber auch hier risiken minimieren:Einige Storage-Hersteller (u. a. IBM) haben KI-Technologien implementiert, die Ransomware-Aktivitäten auf Blockebene erkennen können. In Kombination mit den Immutable Copies der Blöcke ein guter Schutz (aber auch keine 100%).
Hier beschreibt IBM das ganz gut: https://www.ibm.com/support/pages/system/files/inline-files/2024%20Accel ...
1
Moin @ElmerAcmeee,
das ist bei einem LVS oder ERP eigentlich der Normalfall. 🙃
Gut dass ihr euch darüber Gedanken macht, steckt aber eher mehr Zeit in die rein, die dazu führen, dass ein Restore möglichst nicht notwendig ist. 😉
Bitte was ... 😱 ... mehrere Monate für eine Inventarisierung ... das wage ich mal anzuzweifeln ... denn diesen Aufwand müsst ihr einmal im Jahr eh treiben. 🙃
Ja, meiner Erfahrung nach geht das am besten und vor allem auch am transaktionssichersten und sogar auch am günstigsten mit den Bordmitteln des SQL-Server selbst.
Sprich, einfach einmal am Tag die entsprechende DB per Wartungsplan z.B. auf ein NAS sichern und dazwischen mit einem weiteren Wartungsplan, einfach zyklisch, z.B. alle 60 oder 15 oder 5 Minuten oder gar minütlich, sprich nach Bedarf oder Gusto, die Transaktionslogs noch mit wegsichern und schon ist der 🐟 geputzt.
Bitte auch darauf achten, dass die Angreifer möglichst nicht bis an die Backups durchdringen können.
Aber das sollte ja möglichst bei allen Backupszenarien der Fall sein.
Na ja, im schlimmsten Fall einfach auf ein WORM sichern.
By the Way, falls ihr ein gutes und vor allem auch flinkes Backup-NAS/SAN mit ordentlich Kapazität benötigt ...
https://www.infortrend.com/de/products/families/gse/3000
... die Biester gibt es mit bis zu 90 3.5" Bay's auf 4 HE und WORM können die auch. 😉
Gruss Alex
Das System speichert dabei alle Zustände in einer zentralen MS-SQL Datenbank.
das ist bei einem LVS oder ERP eigentlich der Normalfall. 🙃
Nun stolpern wir über den Fall eines eventuellen Restores z.b. nach Ransomware-Angriff.
Gut dass ihr euch darüber Gedanken macht, steckt aber eher mehr Zeit in die rein, die dazu führen, dass ein Restore möglichst nicht notwendig ist. 😉
Sollte dabei der Zustand des Lagers von der SQL DB abweichen, so könnte dies auf eine neue Inventarisierung und einen mehrmonatigen Ausfall hinauslaufen.
Bitte was ... 😱 ... mehrere Monate für eine Inventarisierung ... das wage ich mal anzuzweifeln ... denn diesen Aufwand müsst ihr einmal im Jahr eh treiben. 🙃
Kennt jemand Techniken, die DB „verlustfrei“ zu: duplizieren, backupen, spiegeln, exportieren, … ?
Ja, meiner Erfahrung nach geht das am besten und vor allem auch am transaktionssichersten und sogar auch am günstigsten mit den Bordmitteln des SQL-Server selbst.
Sprich, einfach einmal am Tag die entsprechende DB per Wartungsplan z.B. auf ein NAS sichern und dazwischen mit einem weiteren Wartungsplan, einfach zyklisch, z.B. alle 60 oder 15 oder 5 Minuten oder gar minütlich, sprich nach Bedarf oder Gusto, die Transaktionslogs noch mit wegsichern und schon ist der 🐟 geputzt.
Bitte auch darauf achten, dass die Angreifer möglichst nicht bis an die Backups durchdringen können.
Aber das sollte ja möglichst bei allen Backupszenarien der Fall sein.
Na ja, im schlimmsten Fall einfach auf ein WORM sichern.
By the Way, falls ihr ein gutes und vor allem auch flinkes Backup-NAS/SAN mit ordentlich Kapazität benötigt ...
https://www.infortrend.com/de/products/families/gse/3000
... die Biester gibt es mit bis zu 90 3.5" Bay's auf 4 HE und WORM können die auch. 😉
Gruss Alex
Moin @em-pie,
solche Spielereien kosten meistens jedoch auch massiv Performance. 😔
Ich habe erst dem Letzt ein SAN mit KI, sprich, eine HPE Alletra MP testen dürfen. Dessen Performance war jedoch nicht wirklich sehr berauschen.
Gruss Alex
Einige Storage-Hersteller (u. a. IBM) haben KI-Technologien implementiert, die Ransomware-Aktivitäten auf Blockebene erkennen können. In Kombination mit den Immutable Copies der Blöcke ein guter Schutz (aber auch keine 100%).
Hier beschreibt IBM das ganz gut: https://www.ibm.com/support/pages/system/files/inline-files/2024%20Accel ...
Hier beschreibt IBM das ganz gut: https://www.ibm.com/support/pages/system/files/inline-files/2024%20Accel ...
solche Spielereien kosten meistens jedoch auch massiv Performance. 😔
Ich habe erst dem Letzt ein SAN mit KI, sprich, eine HPE Alletra MP testen dürfen. Dessen Performance war jedoch nicht wirklich sehr berauschen.
Gruss Alex
Moin,
Danke für den ganzen Input.
Um einen Großteil der Angesprochen Themen haben wir uns bereits gekümmert bzw uns Gedanken gemacht
Immutable Backups, Backup Snapshots, Backup Replikat, TapeOut, Hypervisor Cluster, Storage Snapshots, 2 RZs, VLAN Trennung, Zentrale NextGen Firewall, UVM alles schon da...
Einen 100% Schutz wird es IMHO nicht geben.
Dennoch sollte der Anspruch sein, soviel wie möglich abzudecken.
Ob dieser zusätzliche Schutz, den Mehraufwand und die Kosten rechtfertigt, wird man gemeinsam Besprechen und Entscheiden.
Das LVM ist noch nicht gekauft. Es stehen 3 zur Auswahl. Alle arbeiten mit einer zentralen DB.
Für die Ersteinlagerung rechnet man bei allen mit 4 Monaten.
Bei der Neuinventarisierung gibt es wohl Unterschiede...
Meine Eingangsfrage richtet sich nun gezielt auf den Teil der Datenbank selber. Da fehlt mir die Erfahrung.
Ist Logshipping eine Möglichkeit?
Setzt jemand eine CDP-Lösung für SQL ein und könnte etwas empfehlen?
Danke
Danke für den ganzen Input.
Um einen Großteil der Angesprochen Themen haben wir uns bereits gekümmert bzw uns Gedanken gemacht
Immutable Backups, Backup Snapshots, Backup Replikat, TapeOut, Hypervisor Cluster, Storage Snapshots, 2 RZs, VLAN Trennung, Zentrale NextGen Firewall, UVM alles schon da...
Einen 100% Schutz wird es IMHO nicht geben.
Dennoch sollte der Anspruch sein, soviel wie möglich abzudecken.
Ob dieser zusätzliche Schutz, den Mehraufwand und die Kosten rechtfertigt, wird man gemeinsam Besprechen und Entscheiden.
Das LVM ist noch nicht gekauft. Es stehen 3 zur Auswahl. Alle arbeiten mit einer zentralen DB.
Für die Ersteinlagerung rechnet man bei allen mit 4 Monaten.
Bei der Neuinventarisierung gibt es wohl Unterschiede...
Meine Eingangsfrage richtet sich nun gezielt auf den Teil der Datenbank selber. Da fehlt mir die Erfahrung.
Ist Logshipping eine Möglichkeit?
Setzt jemand eine CDP-Lösung für SQL ein und könnte etwas empfehlen?
Danke
Moin,
Gruß,
Dani
Setzt jemand eine CDP-Lösung für SQL ein und könnte etwas empfehlen?
wenn du in der Microsoft Welt bleiben willst ist es Date Protection Manager. Ansonsten 3rd Party gibt Acronis, Double-Take Backup, etc.b dieser zusätzliche Schutz, den Mehraufwand und die Kosten rechtfertigt, wird man gemeinsam Besprechen und Entscheiden.
Denkt auch an die Manpower und an das Personal. Es nutzt nichts die besten Produkte und Lösungen im Haus zu haben, wenn nicht x Personen damit umgehen können. Gerade bei Ausfällen muss jeder Handgriff setzen. Nichts zu vergessen evtl. Rufbereitschaften, etc. wenn das System so unabdingbar für euch ist. Da dürften die Kosten dann auch keinem etwas ausmachen.Gruß,
Dani
1
Moin @ElmerAcmeee,
ja "log shipping" ist auch eine Möglichkeit.
https://learn.microsoft.com/de-de/sql/database-engine/log-shipping/about ...
Ich bin davon jedoch nicht wirklich sehr begeistert, weil das im Grunde nur eine andere Form der Replikation ist.
Sprich, diese Schutzmassnahme hilft wie auch klassische Spiegelung/>=2RZs zwar bei Feuer, Überschwemmung und eventuell auch bei einem Cyber-Angriff der die entsprechende DB von "aussen" beschädigt/verschlüsselt.
Aber, wenn die Angreifer es schaffen auch die Daten innerhalb der DB zu manipulieren, bringt dir eine Spiegelung/Replika/>=2RZs auch nicht wirklich etwas, da die Manipulationen einfach mit gespiegelt werden.
Bei dem von mir beschriebenen Verfahren, hast du jedoch die Möglichkeit die DB zu einem bestimmten Zeitpunkt zurück zu versetzen, sprich vor der Manipulation und zwar auf Transaktionsebene. 😉
By the Way, wenn euch wirklich ein ernster Cyber-Angriff trifft (Vollverschlüsselung/ AD gekapert u.s.w.) und ihr seid mit dem meisten innerhalb von 48 Stunden wieder online und habt im schlimmsten Fall nur Daten von den letzten 24 Stunden verloren, dann habt ihr das Ganze wahrscheinlich zu 99% besser überstanden, wie alle anderen ähnlich Betroffene.
Gruss Alex
Meine Eingangsfrage richtet sich nun gezielt auf den Teil der Datenbank selber. Da fehlt mir die Erfahrung.
Ist Logshipping eine Möglichkeit?
Ist Logshipping eine Möglichkeit?
ja "log shipping" ist auch eine Möglichkeit.
https://learn.microsoft.com/de-de/sql/database-engine/log-shipping/about ...
Ich bin davon jedoch nicht wirklich sehr begeistert, weil das im Grunde nur eine andere Form der Replikation ist.
Sprich, diese Schutzmassnahme hilft wie auch klassische Spiegelung/>=2RZs zwar bei Feuer, Überschwemmung und eventuell auch bei einem Cyber-Angriff der die entsprechende DB von "aussen" beschädigt/verschlüsselt.
Aber, wenn die Angreifer es schaffen auch die Daten innerhalb der DB zu manipulieren, bringt dir eine Spiegelung/Replika/>=2RZs auch nicht wirklich etwas, da die Manipulationen einfach mit gespiegelt werden.
Bei dem von mir beschriebenen Verfahren, hast du jedoch die Möglichkeit die DB zu einem bestimmten Zeitpunkt zurück zu versetzen, sprich vor der Manipulation und zwar auf Transaktionsebene. 😉
By the Way, wenn euch wirklich ein ernster Cyber-Angriff trifft (Vollverschlüsselung/ AD gekapert u.s.w.) und ihr seid mit dem meisten innerhalb von 48 Stunden wieder online und habt im schlimmsten Fall nur Daten von den letzten 24 Stunden verloren, dann habt ihr das Ganze wahrscheinlich zu 99% besser überstanden, wie alle anderen ähnlich Betroffene.
Gruss Alex
Moin,
Notfalls holen wir uns auch nen Dienstleister. Aber dazu muss halt das Konzept passen.
Die genannten Tools werde ich mir mal ansehen. Danke
Däumchen drücken. man darf ja auch mal Glück haben
Danke und Gruß
Zitat von @Dani:
Denkt auch an die Manpower und an das Personal. Es nutzt nichts die besten Produkte und Lösungen im Haus zu haben, wenn nicht x Personen damit umgehen können. Gerade bei Ausfällen muss jeder Handgriff setzen. Nichts zu vergessen evtl. Rufbereitschaften, etc. wenn das System so unabdingbar für euch ist. Da dürften die Kosten dann auch keinem etwas ausmachen.
der Ausfall selber ist nicht ganz so kritisch.Denkt auch an die Manpower und an das Personal. Es nutzt nichts die besten Produkte und Lösungen im Haus zu haben, wenn nicht x Personen damit umgehen können. Gerade bei Ausfällen muss jeder Handgriff setzen. Nichts zu vergessen evtl. Rufbereitschaften, etc. wenn das System so unabdingbar für euch ist. Da dürften die Kosten dann auch keinem etwas ausmachen.
Notfalls holen wir uns auch nen Dienstleister. Aber dazu muss halt das Konzept passen.
Die genannten Tools werde ich mir mal ansehen. Danke
Zitat von @MysticFoxDE:
By the Way, wenn euch wirklich ein ernster Cyber-Angriff trifft (Vollverschlüsselung/ AD gekapert u.s.w.) und ihr seid mit dem meisten innerhalb von 48 Stunden wieder online und habt im schlimmsten Fall nur Daten von den letzten 24 Stunden verloren, dann habt ihr das Ganze wahrscheinlich zu 99% besser überstanden, wie alle anderen ähnlich Betroffene.
By the Way, wenn euch wirklich ein ernster Cyber-Angriff trifft (Vollverschlüsselung/ AD gekapert u.s.w.) und ihr seid mit dem meisten innerhalb von 48 Stunden wieder online und habt im schlimmsten Fall nur Daten von den letzten 24 Stunden verloren, dann habt ihr das Ganze wahrscheinlich zu 99% besser überstanden, wie alle anderen ähnlich Betroffene.
Däumchen drücken. man darf ja auch mal Glück haben
Danke und Gruß
