Daten (aus DB) wiederherstellen - best practis

  • Allgemein

Es gibt 13 Antworten in diesem Thema. Der letzte Beitrag () ist von mrMo.

    Daten (aus DB) wiederherstellen - best practis

    Tach zusammen,

    gegeben sei folgendes Szenario:

    - Adressverwaltung mit Datenhaltung im MS SQL-Server
    - Tägliches Backup (Abends um 23:59 Uh) der DB
    - Benutzer löscht um 15:00 Uhr „ausversehen“ 20 sehr wichtige Adressen
    - Am Vormittag wurden 50 neue Adressen angelegt
    - die Daten einer Adresse sind auf mind. 2 Tabellen verteilt da z.b. unbegrenzt Telefonnummern hinterlegt werden können
    - DB vom Vortag wurde gesichert

    Nun möchte man natürlich gerne diese 20 Adressen wieder haben. Wie geht ihr mit dem
    Thema „Daten(-sätze) wiederherstellen“ um?

    Es geht hier um eure Erfahrung und die „best practis“.

    *Topic verschoben*
    "Gib einem Mann einen Fisch und du ernährst ihn für einen Tag. Lehre einen Mann zu fischen und du ernährst ihn für sein Leben."

    Wie debugge ich richtig? => Debuggen, Fehler finden und beseitigen
    Wie man VisualStudio nutzt? => VisualStudio richtig nutzen

    Dieser Beitrag wurde bereits 4 mal editiert, zuletzt von „Marcus Gräfe“ ()

    Das ist nahe zu unmöglich, denn du hast vermudlich schon in die Datei geschrieben und die alten Daten überschreiben
    aber du könntest es mit
    diskgenius.com/
    minitool.com/
    easeus.com/data-recovery-software/
    und mit
    partitionwizard.com/free-partition-manager.html

    probieren, du könntest aber auch hingeben und nach dem Header auf der Festplatte deiner Datei suche und versuchen speicher der hinter der Datei liegt zu der Datei hinzufügen, wird nur kacke, wenn die Daten verstreut sind
    @facebamm: Du hast da wohl etwas falsch verstanden. Die Daten sind noch im BackUp enthalten. Die Frage ist nun , wie stellt man diese am Besten wieder her, ohne die neuen Daten zu verlieren.

    @mrMo: Ich sehe da einen Konzeptfehler wenn ein Benutzer Daten "ausversehen" oder gar bewusst löschen kann.
    Grundsätzlich bin ich für das Markieren als gelöscht und damit nicht mehr sichtbar.

    In dem beschriebenen Fall denke ich dass es Möglich wäre das BackUp in eine andere Datenbank wieder herzustellen und die gelöschten Daten auf SQL-Ebene wieder in die Produktiv einzuspielen.
    Im Zweifel muss die Produktivanwendung angehalten werden und auf den Tabellen die Identity für die Wiederherstellung geändert werden, um die Datensätze mit der alten ID einzufügen.
    Die deutsche Sprache ist Freeware, du kannst sie benutzen, ohne dafür zu bezahlen. Sie ist aber nicht Open Source, also darfst du sie nicht verändern, wie es dir gerade passt.
    @MrTrebron danke für deine Antwort. Ein Löschflag wäre ein möglicher Weg.

    Bin gespannt was für alternative Wege hier noch genannt werden.
    "Gib einem Mann einen Fisch und du ernährst ihn für einen Tag. Lehre einen Mann zu fischen und du ernährst ihn für sein Leben."

    Wie debugge ich richtig? => Debuggen, Fehler finden und beseitigen
    Wie man VisualStudio nutzt? => VisualStudio richtig nutzen
    DB-Typ?

    MySQL, MSSQL, NoSQL, ...?

    Theoretisch könntest du dir das Backup wie @MrTrebron sagte als DB reinziehen und dann über eine Stored Procedure die Daten abgleichen.

    Du sagtest du hast zwei Tabellen für die Daten, das kannste ja dann auch zusammenführen in einer Query.

    So hast du da parat, wann du es brauchst und kannst das theoretisch direkt mit einer Insert-Funktion wieder reinbasteln.

    Soweit ich weiß haben die ganzen großen Systeme auch sowas wie Cron Jobs, mit welchem du das sogar automatisiert machen könntest:

    z.B. MySQL: stackoverflow.com/questions/21…mysql-query-as-a-cron-job

    Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von „Snickbrack“ ()

    Heyho,
    bei mir auch immer mit Löschflag oder ich schiebe gelöschte Einträge in eine Identische Tabelle ala "tblname_deleted".
    So kann ich sicherstellen das aus versehen gelöschte Inhalte noch wiederherstellbar sind.
    Dazu natürlich noch tägliche Datenbank Backups.
    Grüße , xChRoNiKx

    Nützliche Links:
    Visual Studio Empfohlene Einstellungen | Try-Catch heißes Eisen
    Danke für die Antworten.

    Wie würdet ihr das Thema „löschen“ von Datensätzen (mit „Rückgängig Funktion) im Allgemeinen umsetzen? Datenhaltung hier der MS SQL-Server 2014 Express (und neuer).
    "Gib einem Mann einen Fisch und du ernährst ihn für einen Tag. Lehre einen Mann zu fischen und du ernährst ihn für sein Leben."

    Wie debugge ich richtig? => Debuggen, Fehler finden und beseitigen
    Wie man VisualStudio nutzt? => VisualStudio richtig nutzen
    Hey,
    also wie ich ja schon schrieb (evtl. überlesen) gibt es in den meisten Fällen bei mir einen "Löschflag" und der kann jederzeit wieder
    umgestellt werden. (Löschflag: 1=ausblenden / 0=anzeigen)
    So wird nichts endgültig gelöscht und hat die Datensätze noch da falls was ist.

    Neuerdings verschiebe ich die Datensätze eher in eine neue fast Identische Tabelle "tbl_name_deleted"
    diese hat zusätzlich ein DATETIME damit man weiß wann die "Löschung" stattfand.
    So kann ich einfach gelöschte Datensätze wieder zurückholen.
    Sogar ziemlich genau wenn der Kunde weiß wann er gelöscht hat.

    Und die Täglichen Backups nicht vergessen.

    Ich weiß nicht inwieweit sich das MS SQL-Server von MySQL unterscheidet aber das sollte da ja auch gehen geh ich mal von aus.
    Evtl. gibt es da ja bessere Lösungen als die die ich hier immer verwende.
    Grüße , xChRoNiKx

    Nützliche Links:
    Visual Studio Empfohlene Einstellungen | Try-Catch heißes Eisen
    @xChRoNiKx Was wenn sich der Datensatz auf mehrere (sagen wir 10) Tabellen verteilt?
    "Gib einem Mann einen Fisch und du ernährst ihn für einen Tag. Lehre einen Mann zu fischen und du ernährst ihn für sein Leben."

    Wie debugge ich richtig? => Debuggen, Fehler finden und beseitigen
    Wie man VisualStudio nutzt? => VisualStudio richtig nutzen
    Jup auch dann mache ich das mit der "tbl_name_deleted" in MYSQL gibt es Trigger da kann man halt noch Sachen vor oder nach INSERT/DELETE usw ausführen.
    Und da wird dann für jede Tabelle halt ein Trigger erstellt der beim DELETE die ganze Zeile in die Deleted Tabelle Inserted.

    Ich kann mir schon denken das es evtl. echt nicht das beste ist und vielleicht auch Fehldesign von meiner Seite aus ist,
    aber mir fiel nichts anderes ein um das "zurück" holen einfacher zu machen.
    Grüße , xChRoNiKx

    Nützliche Links:
    Visual Studio Empfohlene Einstellungen | Try-Catch heißes Eisen
    Hi,

    Löschung auf Datenbank-Ebene
    ich schlage vor du machst es mit einem delete flag, d.h. du löschst den Datensatz nicht tatsächlich (noch nicht) sondern merkst ihn damit nur zur Löschung vor.
    Ein noch effizienterer Ansatz könnte es sein, ein delete DateTime (oder INT für einen Timestamp) flag zu machen, das standardmäßig auf NULL ist. Wenn der Datensatz "gelöscht" wird, setzt du den aktuellen Timestamp als Wert. Ein CronJob Eintrag prüft zyklisch z.B. nach 30 Tagen, welche Datensätze gelöscht werden können (also DateTime Wert des Datensatzes +30 Tage und nicht fix sowas wie "am 1. des Monats", sonst verlierst du Datensätze die z.B. am Vortag erst frisch als gelöscht markiert wurden). Der CronJob führt dann eine whatever Datei aus mit einem Befehl ähnlich wie

    SQL-Abfrage

    1. DELETE FROM `TABELLE` WHERE `DELETED` < UNIX_TIMESTAMP(DATE_SUB(NOW(), INTERVAL 90 DAY));


    Du schaffst dir zusätzliche Flexibilität wenn alle (oder die meisten) Tabellen so ein Feld haben, dann kannst du dynamisch alle Tabellen der DB durchgehen und die records löschen. Überlege ob das für deine Situation Sinn machen kann.

    Tipp: überlege, welche Lösch-Strategie hier für dich besser passt, denn wenn du den aktuellen Timestamp hinterlegst, musst du fix und global (und unveränderbar) definieren, nach wievielen Tagen der Datensatz gelöscht wird. Du kannst also nicht sagen dass die Daten aus Tabelle "A" 30 Tage behalten werden sollen und für Tabelle "B" dann 90 Tage.
    Um das zu umgehen kannst du auch als Timestamp den Zeitpunkt der Löschung festlegen, z.B. "in 30 Tagen". Du siehst, bei der ersten Idee setzt du als Wert den Zeitpunkt wann er als gelöscht markiert wurde, wohingegen du bei der zweiten Idee den Zeitpunkt festlegst, zu dem der Datensatz tatsächlich gelöscht werden soll. Die zweite Idee hat hier einen großen Vorteil, nämlich dass du individuell je nach Datensatz oder Tabelle festlegen kannst, wann er endgültig gelöscht wird.

    Hier macht's einen Unterschied ob die Daten von einem Admin wiederhergestellt werden sollen oder ob der "Endkunde" (?) diesen Vorgang selbst ausführen können soll (z.B. eine Adresse die der Kunde versehentlich gelöscht hat, die er aber auch selbst wieder herstellen kann). Mein genannter Vorschlag wäre praktisch für beide Fälle und entlastet damit den Aufwand seitens des Dienstanbieters, d.h. der Admin muss nicht aktiv tätig werden und eingreifen.

    Alternativ kann diese Idee abgewandelt werden, sodass die Löschung z.B. in einem zwei- oder mehrstufigen Verfahren stattfindet.
    Beispiel:
    1) Kunde klickt bei der Adresse auf "Löschen" (wodurch der Datensatz in einer Art Papierkorb landet)
    2) Der Datensatz befindet sich im Papierkorb, sodass er im Zeitraum von 30 Tagen vom Endkunden jederzeit selbst wiederhergestellt werden kann.
    3) Nach den 30 Tagen wird automatisch ein Lösch-Flag gesetzt - so dass der Kunde ihn nicht mehr sehen und wiederherstellen kann, er aber immer noch in der Datenbank vorhanden ist (was bedeutet dass nur du ihn sehen und ggf. wieder reaktivieren kannst).
    4) Nach einem Jahr werden dann solche Datensätze tatsächlich gelöscht, also richtig mit DELETE undso.

    Diese Idee bringt den zusätzlichen Vorteil dass du derlei Daten innerhalb dieser 365 Tage wirklich ohne Aufwand und ganz einfach wiederherstellen kannst (Bonus: lass den Kunden diesen "manuellen Eingriff" zusätzlich bezahlen).

    Achtung: informiere dich über gesetzliche Regelungen zu Löschung und Aufbewahrungsfristen, manche Daten müssen auf Anfrage unwiderruflich und mit sofortiger Wirkung gelöscht werden können wohingegen es bei manchen Daten eine Aufbewahrungsfrist gibt, d.h. eine Zeit (z.B. 10 Jahre) in der die Daten jederzeit verfügbar, nachweisbar und abrufbar sein müssen.

    Backup
    Wenn wir tatsächlich von einer Backup-Lösung sprechen, ist das nichts womit der Endkunde zu tun hat, außerdem auch ein anderes Thema.
    Je nachdem wie brisant die Daten sind, gibt es hier auch mehrere Ansätze, gerade beim Thema Backup gibt es hier nicht DIE Lösung, im Gegenteil fährt man am effizientesten, sich gut durchdachte Backupkonzepte- und Strategien zu überlegen, die optimal auf die technischen Begebenheiten abgestimmt und zugeschnitten sind (check den Link). Unabhängig von Backup-Strategien kannst du die Datenbanken auch über einen externen Server spiegeln ("database mirroring", lies hierzu diesen Artikel).

    Datenbank Backup und Mirroring kannst du in Kombination mit der oben genannten Pseudo-Löschung (mit dem delete flag) verwenden (was ich auch empfehlen würde).

    PS: "best practices" sind eine tolle Sache, können aber oft nur für dedizierte Prozesse herangezogen werden. Speziell wenn's um Datenstrukturen oder Backup-Mechanismen geht kannst du hier nicht mehr "abschauen wie andere es machen" und diese Schritte 1:1 übernehmen, dazu sind die Gegebenheiten zu komplex - best practice Lösungen wirst du hier nur stark verallgemeinert vorfinden.


    Link :thumbup:
    Hello World

    Dieser Beitrag wurde bereits 7 mal editiert, zuletzt von „Link“ ()

    @Link Danke für deine Antwort. Löschflag in Kombination mit nem TimeStamp find ich sehr sinnvoll. Damit stehen mir alle Wege offen :)
    "Gib einem Mann einen Fisch und du ernährst ihn für einen Tag. Lehre einen Mann zu fischen und du ernährst ihn für sein Leben."

    Wie debugge ich richtig? => Debuggen, Fehler finden und beseitigen
    Wie man VisualStudio nutzt? => VisualStudio richtig nutzen