Daten archivieren, DB XML Exports machen und per Mail verschicken

[Gomix]

Hi.

Ich mach mir gerade Gedanken darüber, wie ich eine Datenarchivierung realisiere.

Ich programmiere ein Projekt, welches eine mysql Datenbank verwendet.
Das wird später aus Kostengründen auf einem shared Hosting oder einem vServer laufen.

Das Problem ist folgendes: bei einem shared Hosting oder v-Server ist man grundsätzlich eingeschränkt, was die Backup Möglichkeiten angeht.
Außerdem hat man, gerade am Anfang, noch ein großes Risiko, dass man irgendwelche Sicherheitslücken drin hat.
Ein regelmäßiges Backup ist also erforderlich.
Erster Ansatz ist erst mal, jeden Tag einen DB Dump zu machen und zusammen mit dem gesamten ProjectDir auf den Privatrechner zu laden. Aber das kann man natürlich auch mal vergessen.

Bei meinem Projekt werden auch kostenpflichtige Leistungen angeboten, deren Preise sich öfter mal ändern und wegen scriptgesteuerter Sonderaktionen auch bei einzelnen Usern unterschiedlich sein können.
(z.B. 25% Rabatt für Bestellungen in den ersten 24h nach Anmeldung)

Ein weiteres Problem ist z.B., dass ein User nach der erfolgen Anmeldung die Daten nachträglich ändert oder den Account wieder löscht. Es müsste also auch eine History geschrieben werden, um jederzeit nachvollziehen zu können, wie der Datenbestand bei Auslösung der Bestellung gerade war.

Zur Bereinigung der Datenbank werden dann Historys nach einer gewissen Zeit wieder gelöscht und müssen im Fall der Fälle aus den Dumps wiederhergestellt werden.

Ein Problem an den Dumps ist, dass sich in der Entwicklungsphase das Datenbankenlayout ändern kann und ältere Dumps dann evtl nicht mehr passen. Ausserdem ist es schwierig, einzelne Positionen aus den großen Dump Files rauszufischen.

Nun kam mir die Idee, das Ganze so zu realisieren:
Bei wichtigen Useraktionen wie z.B. Anmeldung, Löschung oder Adressänderung wird die History in einer separaten XML Datei weg gespeichert.

Bei Bestellungen wird die ganze Bestellung in einer XML Datei exportiert und weg gespeichert.

Diese XML Dateien gehen automatisch per eMail an den Administrator, und sind damit dann auch gleich schonmal außerhalb der Hostingumgebung, und für Manipulationen nicht mehr erreichbar.

Solche Sachen gehen als Bestätigungsmail sowieso schon an den User und an den Admin raus. Bei der Admin Mail könnte man dann auch gleich den XML Export mit anhängen.
Zusätzlich könnte man eine Tageszusammenfassung als XML Datei an den Admin rausschicken, so dass wirklich wichtige Sachen notfalls noch im email Konto des Admins liegen.

Was haltet ihr davon?

[G.Schuster]

Nix.
Wenn du Histories später brauchst lösche sie nicht.
Wenn du Backups brauchst lege welche an anstatt zu versuchen, Krückenlösungen zu implementieren.
Bei den heutigen Preisen für vServer kannst du auch keinem mehr erzählen, dass du aus Kostengründen keine Backups machen kannst.
Zumal das auf einem vServer sowieso die leichteste Übung ist, da du tun und lassen kannst was du willst, immerhin musst du den Server sowieso selbst up2date halten.
Die einfachste und kostengünstigste Backup-Strategie wäre dann wohl, die Dumps vom 10 Euro-vServer per FTP auf einen 5 Euro-Webspace bei einem anderen Anbieter übertragen zu lassen und die Scripte schlicht in eine Versionsverwaltung zu packen.

[alxy]

Du machst die ganz scön viele gedanken über eine Applikation die von der Skalierung her auf nen shared Host passen soll.

Ich würde das Datenbankbackup machen (viele Provider machen sowieso täglich eines an das man auch relativ unproblematisch rankommt) und den Rest mal ganz schnell wieder vergessen.

Edit: ich seh grade, bei strato sogar stündlich: http://www.strato-faq.de/1147

[Gomix]

Ja, das Problem am vServer ist: Wenn ich die Daten per Cronjob in ein extra Verzeichnis schiebe, sind sie immer noch auf dem Server und somit potentiell in Gefahr.

Sie müssen außerhalb des vServers oder Hostings gelagert werden. Am sichersten wäre eine Lösung, bei der die Daten so weg geschickt werden, dass bei einer Kompromittierung des Servers/Hosting trotzdem niemand an die Backups ran kommt. Bei Shared Hosting kann ich sowieso oft keine FTP Verbindung vom Hosting ausgehend auf einen anderen Server herstellen.
Ich müsste die Daten von einem anderen Server ausgehend (z.B. Homeserver) per Cronjob herunterladen.

Das bringt mir aber nix, wenn um 18:51 bestellt wird, die Coins verbraten werden und um 18:52 per SQL Injection die Bestellung manipuliert wird und der Angreifer vielleicht noch nen Server Login erhält und die History manipuliert.

Außerdem müsste man die Logs und die Infos was wann wieviel für diesen Account gekostet hat auf ewig mit in der Datenbank mitschleifen.

Sind bisher nur theoretische Überlegungen, wie man sich davor schützen kann. Natürlich passt man auf, keine Löcher zu lassen. Aber niemald ist perfekt.

Wenn irgendwo anders noch Logs sind, welche zeitnah abgeschickt wurden (Am Besten mit Buchung der Bestellung) wo der Angreifer nicht ran kommt, kann man es zumindest noch rückabwickeln und eventuell raus bekommen wer es war.

[Gomix]

Interessant zu wissen, dass Strato stündlich automatisch nen Backup macht. Mein Hoster macht überhaupt nix bzw nur wenn die selbst was am System machen. Aber bislang habe ich auch noch nix grosses am laufen das ist das nicht schlimm. Bin momentan noch in der Alphaphase und am Konzept erstellen.

Vielleicht sollte ich zu strato gehen wenns mal soweit ist.

Zu meinem Konzept gehört jedenfalls, mir zu überlegen, wie ich die Daten "sicher" weggespeichert bekommt und man im Falle eines Hacks oder einer Harvarie wieder herstellen kann.
Und wie ich auch alle Accounaktivitäten lückenlos dokumentieren kann und jederzeit sagen kann "Am XX.XX.XXXX" war das und das ohne dass die DB zu gigantisch wird.

[akretschmer]

Hi.

Ich mach mir gerade Gedanken darüber, wie ich eine Datenarchivierung realisiere.

Ich programmiere ein Projekt, welches eine mysql Datenbank verwendet.
Das wird später aus Kostengründen auf einem shared Hosting oder einem vServer laufen.

Das Problem ist folgendes: bei einem shared Hosting oder v-Server ist man grundsätzlich eingeschränkt, was die Backup Möglichkeiten angeht.

Wie das? Bei uns bekommst z.B. Storage-Platz. Physisch woanders (anderer Stadtteil) Via Menü definierst Deine Backups.

Außerdem hat man, gerade am Anfang, noch ein großes Risiko, dass man irgendwelche Sicherheitslücken drin hat.
Ein regelmäßiges Backup ist also erforderlich.

Nicht nur am Anfang.

Erster Ansatz ist erst mal, jeden Tag einen DB Dump zu machen und zusammen mit dem gesamten ProjectDir auf den Privatrechner zu laden. Aber das kann man natürlich auch mal vergessen.

Jupps. Sowas automatisiert man.

Bei meinem Projekt werden auch kostenpflichtige Leistungen angeboten, deren Preise sich öfter mal ändern und wegen scriptgesteuerter Sonderaktionen auch bei einzelnen Usern unterschiedlich sein können.
(z.B. 25% Rabatt für Bestellungen in den ersten 24h nach Anmeldung)

Das beachtet man in seinem Datenmodel.

Ein weiteres Problem ist z.B., dass ein User nach der erfolgen Anmeldung die Daten nachträglich ändert oder den Account wieder löscht. Es müsste also auch eine History geschrieben werden, um jederzeit nachvollziehen zu können, wie der Datenbestand bei Auslösung der Bestellung gerade war.

Dafür gibt es TRIGGER-basierte Lösungen z.B., die alle Änderungen loggen. Mal so als Ansatz.

Zur Bereinigung der Datenbank werden dann Historys nach einer gewissen Zeit wieder gelöscht und müssen im Fall der Fälle aus den Dumps wiederhergestellt werden.

Nur als Hinweis: Table-Partitionierung wurde schon erfunden.

Ein Problem an den Dumps ist, dass sich in der Entwicklungsphase das Datenbankenlayout ändern kann und ältere Dumps dann evtl nicht mehr passen. Ausserdem ist es schwierig, einzelne Positionen aus den großen Dump Files rauszufischen.

Wenn Du in Dumps nach Daten suchst machst definitiv was falsch.

Nun kam mir die Idee, das Ganze so zu realisieren:
...
Was haltet ihr davon?

Abstand.

[Gomix]

Vielen Dank für die Hinweise.
Zunächst werde ich mich mal in die Themen Trigger und Table Partitioning einlesen und diese Techniken entsprechend berücksichtigen.

Dann werde ich mich nach einem Provider umsehen, der entsprechende Backup Möglichkeiten bietet und wo ich auch an die Backups ran komme. Selbst wenn der Provider sichert, heißt das nicht, dass ich nicht noch zusätzlich eigene Backups mache. Bei meinem derzeitigen Provider kann man nur umständlich mit nem eigenen PHP Script die Daten aus der Datenbank in eigene Files wegschreiben, bzw über eigene Scripte wieder einspielen.
Nen richtiges automatisiertes mysql Dump ist bei meinem Privider nicht möglich. Man kann es nur manuell über das Kundeninterface starten und bekommt dann das Dump File zum Download, bzw kann dann über das Kundeninterface die DB aus nem Dump wiederherstellen. Da muss der aktuelle Entwicklungsstand der App und das Dump file natürlich zusammen passen oder man lässt das dump auf ne neue DB laufen und kopiert dann von da mittels eigenen PHP Scripts in die App-DB.

Bei den V-Servern wird auch keine externe Backup Kapazität ausserhalb des v-servers geboten. Das einzigste was geboten wird sind "Snapshots" die man sich anlegen lassen kann, an die man aber nicht so ohne Weiteres ran kommt. Man kann den Server nur als ganzes mit so nem Snapshot neu aufsetzen lassen.

Es handelt sich aber auch um einen kleinen "Dorfprovider" der seinerseits mit Mietservern arbeitet und dann entsprechende Hostingkapazitäten verkauft.