Serverausfall - Neue Boardsoftware - Bitte lesen

Stimmt, Sascha. Das kenne ich von meinen Maschinen. Aber dafür ein Softwareraid nehmen? Ein nicht startender mdraid-Treiber kann einen beim Bootvorgang echt in den Wahnsinn treiben. Zudem wird beim Laden des Kernels nur eine Platte des so gebauten Raid1 benutzt, weswegen das überhaupt gar keinen Sinn ergibt. Mit einem vernünftigen Raidcontroller kann man auf einem Raidset mind. zwei logische Laufwerke publizieren. Aber gut, das mag der Unterschied zwischen eigenen hochwertigen Servern und irgendwelchen Mietservern sein, die einfach nur bei wenig monetären Einsatz maximalen Gewinn ausschütten sollen.

Ist ja auch für das Thema ansich irrelevant.

Gerne würde ich mich bereit erklären, Jens beim Erstellen einer künftigen Backupstrategie zu unterstützen, sofern erwünscht.

Zitat von Jens [NFCBW]

[lexicon]THX[/lexicon], ich bastel mir gerade nen Script was dann per cron das macht
- mysql dump
- gzip mysql dump
- tar auf verzeichnis
vom prinzip kann ich dann noch beides zusammenpacken aber die rechenleistung spare ich mir

Zitat von Jens [NFCBW]

dann muss ich es nur noch runterladen, schaut dann so aus wie im screenshot
somit ist dann alles tar gepackt in einem archiv und es geht nichts mehr verloren.

Zitat von Jens [NFCBW]

Dann muss ich halt nur schauen wie oft ich das ganze runter lade

Ich verwende http://sourceforge.net/projects/automysqlbackup/
Astrein programmiert und anpassbar.

Gruß
Sascha

Hübsch ist anders aber selbst daran werden wir uns gewöhnen!

Super Jens was Du alles schaffst und, in Deiner Freizeit, machst!!

Zitat von Kubek

...das [lexicon]NisBo[/lexicon] wird schon.
Das Wichtigste geht doch, Weiteres kommt mit Zeit noch hinzu, denke ich.

Nur muss man sich noch an das Neue gewöhnen und gut ist. Auch wenn es gerade mir - der Neuerungen hasst - recht schwer fällt.

Bei problemen pn

Dafür muss ich mal den pc anmachen Bin mit handy online. Warte 10min und ich teste es mal. aber heute mittag ging es.

ich habe [lexicon]FAST[/lexicon] überall oben so eine Fehlermeldung oder Hinweiswarnung, keine Ahnung was es sein soll...

Seitenanfang:
(daneben immer mal irgend ne Zahl)

Seitenende:
(steht nix daneben)

außerdem wenn ich das wort [lexicon]FAST[/lexicon] benutze, hat des nichts mit Nissan [lexicon]FAST[/lexicon] zu tun.

Also das Glas ist [lexicon]FAST[/lexicon] leer. ne so nix Nissan...

(is mir zumindest halt aufgefallen)

Zitat von Jens [NFCBW]

[lexicon]THX[/lexicon], ich bastel mir gerade nen Script was dann per cron das macht
- mysql dump
- gzip mysql dump
- tar auf verzeichnis
vom prinzip kann ich dann noch beides zusammenpacken aber die rechenleistung spare ich mir

dann muss ich es nur noch runterladen, schaut dann so aus wie im screenshot
somit ist dann alles tar gepackt in einem archiv und es geht nichts mehr verloren.

Dann muss ich halt nur schauen wie oft ich das ganze runter lade

Alles anzeigen

Zuerst ein TAR-Archiv anlegen und dann zu komprimieren (bzw tar mit der Option -z ) wäre der elegantere Weg. Noch besser wäre bzip2

Versuch es so:

#!/bin/sh




# Dump erzeugen und unter /backup ablegen




/usr/bin/mysqldump --password='PASSWORT' --user=root -A --events > /backup/mysql.`date +%Y-%m-%d`.dump || /usr/bin/mail webmaster@nissanboard.de -s "mysqldump Fehler"




# Nur die letzten 7 Tage nachhalten




cd /backup




num=7
count=`ls -1 mysql* | wc -l`




if [ $(($count-$num)) -gt 0 ]; then
       for i in `ls -1 mysql* | head -n $(($count-$num))`; do
               rm $i
       done
fi




for name in `ls -1 mysql*dump`; do
       if [ ! -e $name.bz2 ]; then
               bzip2 $name;
       else
               mv $name error-$name;
               /usr/bin/mail webmaster@nissanboard.de -s "mysqldump bzip2 Fehler"
       fi
done

Dann hast du die MySQL-Dumps der letzten 7 Tage vorgehalten.

Zusätzlich würde ich dann noch das etc-Verzeichnis sichern:

#!/bin/sh




FILENAME=etc.tar.bz2




# prüfen, ob es die Datei schon vorhanden ist




if [ -e /backup/$FILENAME ]; then
        rm -f /backup/$FILENAME
fi




# Das etc-Verzeichnis archivieren und mit bzip2 komprimieren.




tar cjf /backup/$FILENAME /etc || /usr/bin/mail webmaster@nissanboard.de -s "etc backup Fehler"

Somit hast du schonmal die Dumps und die Konfiguration der Maschine unter /backup liegen und brauchst dir das nur regelmäßig wegsichern. Ich nehme dafür gerne rsnc. Damit transferierst du dann nur die Dateien auf eine andere Maschine, die sich seit dem letzten rsync geändert haben. Das würde sich auch für das HTDOCS-Verzeichnis anbieten. Im Grunde reicht ein kleiner v-server für 6,95€ monatlich dafür aus, um die Daten per cronjob nachts durch einen SSH-Tunnel rüber zu schicken. Das hätte den Charme, dass du im Restorefall nur das HTDOCS-Verzeichnis und das Backup-Verzeichnis zurückspielen musst, das dump-file in die [lexicon]Datenbank[/lexicon] zurückspielst und du somit wieder binnen kürzester Zeit das alte System lauffähig hast.