Datensicherung aus Forum und Story?
Eingetragen von Nashuja (123)am 27.02.2009 - 12:08 Uhr in
Hi alle,
Ich hab mal eine Frage zu einem kommenden Problem für mein zukünftiges Projekt.
In dem System was ich erstellt habe, werden in einem dafür angepaßtem Drupalforum *Komplettes Forum Namentlich angepasst*
Übergaben gepostet. Welche weder Editiert werden dürfen noch gelöscht *geregelt über Forum Access*.
Das eigentliche Problem ist folgendes:
Diese Übergaben *postings* müssen 30 Jahre verwahrt werden....
Um die Übersicht in dem "Forum" zu behalten im laufe der Jahre und zu vermeiden das die DB und Filesystem brutal Anschwillt,
suche ich nach einer Möglichkeit z.b. bestimmte Abschnitte des Forum entweder zu Sichern oder zu Exportieren und aus dem System zu entfernen.
Bei Story auch wenns geht, aber Wichtig wäre die Externe Sicherung der Foreninhalte.. evnt sogar so, das man diese in einem anderem Programm Leserlich hat.
Hat vieleicht irgendwer nee Idee dazu oder kennt eine Möglichkeit das zu realisieren?
Wäre sehr Wichtig für mich.. da ich bei xx Subdomains *1 Dokumentierenden Betrieb pro subdomain* auf den servern sonst fix die Grenzen, selbst bei 100gig Speicherplatz erreiche. Zumal die DB im laufe der Zeit ins unermeßliche Anschwellen würde.
thx schon mal..
Michael
*Die DB des Grundsystems hat jetzt schon satte 10,5 MB - kann man sich ja Vorstellen was die erst hat wenn nen Betrieb 1 jahr damit gearbeitet hat
Zumal die PHP Einstellungen für Import bei 65 MB liegen. Was ja schon eine system Wiederherstellung nach nem 1/2 Jahr, falls das system crasht unmöglich macht.
Außer ich lass die Daten für nee menge Geld, per CD im Datacenter direkt einspielen:P OoO
Drupal 6.10
- Anmelden oder Registrieren um Kommentare zu schreiben
Hallo Michael
am 27.02.2009 - 13:32 Uhr
Dein Posting ist etwas verwirrend.
Diese Übergaben *postings* müssen 30 Jahre verwahrt werden....
Sichere Lösungen:
*Die DB des Grundsystems hat jetzt schon satte 10,5 MB - kann man sich ja Vorstellen was die erst hat wenn nen Betrieb 1 jahr damit gearbeitet hat
Zumal die PHP Einstellungen für Import bei 65 MB liegen. Was ja schon eine system Wiederherstellung nach nem 1/2 Jahr, falls das system crasht unmöglich macht.
Also: wenn du das auf einem billigen Webspace machen willst, auf dem du keinen shell access hast, dann hast du eventuell einen Fehler gemacht, als du die Anforderungen für dein Projekt abgesteckt hast. Ich habe eine Drupal-Installation mit einer über 50 MB großen Datenbank. Die DB wird über shell skripte gesichert und auf einen zweiten Server geschoben. Das geht auch mit 100 mb großen Datenbanken.
Bei einem Projekt, was sicher laufen soll ist ein regelmäßiges automatisches Backup auf einem extra-server unabdingbar. Speicherplatz ist billig, und wird immer billiger.(ZB hier: http://aws.amazon.com/s3/#pricing)
Die Sicherung soll nicht im
am 27.02.2009 - 14:09 Uhr
Die Sicherung soll nicht im Web liegen.. ansonsten wärs ja simpel OoO
*DB Sicherung und Löschung der älteren Beiträge
*Nur müsste ich bei ner Wiederherstellung dieses in ein DP System gleicher Konfiguration wieder einspielen um die Daten einzusehen.
Es soll nee Sicherung sein und gleichzeitige löschung der gesicherten Daten, welche z.b. in PDF lesbar sind oder so oder so ähnlich.
Der Webspace ist Garantiert nicht Billig^^ Ist nen Reseller und per Antrag könnte ich selbst den phph wert erhöhen lassen (Die 65 MB sind Standdart Einstellung des Hosts).. ist aber nicht Sinn und Zweck des ganzen^^
Punkt 1. = Quak^^
Punkt 2. = Megaquak^^ OoO
Punkt 3. = Das system soll Papier sparen und nicht vebrauchen^^
Es geht nur um eine Exportierung (evnt inkl direkter Löschung der Sicherung* in ein Offlineformat.
Mal abgesehn davon, dass DBs
am 27.02.2009 - 14:55 Uhr
Mal abgesehn davon, dass DBs im MB Bereich ein Scherzlein sind, hier ein technisch funktionierender Ansatz:
- Setzt einen lokalen Drupal-Server auf
- Du bedienst Dich der Services (http://drupal.org/project/services)
- Der synchronisiert alles (als cron_hook) zu sich lokal
- und löscht die entsprechenden Nodes auf dem Live System
- Machst einmal Im Jahr ein DB-Backup (als Dump) vom Lokalen und löschst da die Nodes
Das, wo man da bei aufpassen muss: Die Node-IDs müssen beibehalten werden. Das ist aber easy.
Alles in allem bei dem Problem ein eher theoretischer Ansatz und der Aufwand übersteigt da bei weitem den Nutzen.
Sinn macht das allenthalben, wenn es um GB von Daten pro Jahr geht.
1 GB Daten (samt Overhead für Index etc) sind immerhin 250.000 vollgeschriebene DIN A4 Seiten, vorrausgesetzt man hat da jetzt keine speicherfressenden Anhänge dran.
k.. sehr Nice.. das ist doch
am 27.02.2009 - 17:30 Uhr
k.. sehr Nice.. das ist doch nen sehr schöner Ansatz.. danke.
Und MB Bereich werd ich pro DB sicherlich sprengen^^ Ein DB eines Betriebes der Testversion des Systems, die ca 6 Monate lief hat 102.57 MB. Also das läppert sich schon dolle wenn man es mal auf 4-5 Jahre Hochrechnet.
Geplant sind pro Server *sind Dedicated Reseller mit vorgemieten der Stammdomain angepassten Domainnames a 100gig Save, 100gig Transfer fest, Highend Dellserver in seperatierter Serverfarm, mit allen Extras an Sicherheitsstanddarts die es atm gibt, 2x Täglich laufen Serverbackups usw* so ca um die 50-80 Subdomains, wobei jede nee eigene MSQL DB hat. Anzahl wird Abhängig von der gemessenen Serverlast dann...
Die Datenmenge ist eher nicht das Problem.. sondern wird erst zu nem Problem, wenn es auf Sicherung und Wiederherstellung ankommt *Serverbackups ausgeschlossen da ich ja einzele subdomains Notfalls wiederherstellen muss ohne andere zu überschreiben*.
Von daher ist dein Tipp schon nee nette Lösung... wobei ich mal schauen muss ob ich das ganze dann nicht Local sondern auf sepperatem Server teste.
Hab mir inzwischen einiges an Export/import Modulen angeschaut, allerdings bisher nix ausreichendes dabei gewesen, wenn müsste man die derbe anpassen.
Naja, mal schauen..
mfg
Michael
Na wenn da noch ein Server frei ist
am 27.02.2009 - 17:43 Uhr
Die anskizzierte Lösung ist ja Pull-Technik. Wenn Dein "Backup"-Server auch öffentlich zugänglich ist, dann wäre es eleganter die Logik auf dem Live zu behalten.
Super prima geht das mit Einbindung von Rules (http://drupal.org/project/rules) und dem integrierten Scheduler.
Sprich: Nach erfolgreichem Backup mit Rules und Services, löscht Rules einfach den Node.
Das gleiche in Grün nur als Push-Dienst.