- Mitglied seit
- 15. Mai 2008
- Beiträge
- 21.900
- Punkte für Reaktionen
- 14
- Punkte
- 0
hi leutz,
hab die 207+ erst seit Mitte des Monats und natürlich noch ganz viele Flausen im Kopf, was man mit dem Ding anstellen kann. Da mittlerweile mein RAID1 schon zweimal herhalten musste (neue Synchronisation), mach ich mir schon Gedanken, was passieren wird, wenn beide Platten sich nicht mehr rühren
Hab hier im Forum ein wenig herum geschmöckert und festgestellt, dass es wohl auch berechtigt ist, sich Gedanken zur Datensicherung zu machen. Klar, die 'gemeinsamen' Ordner kann man locker sichern. Aber was macht man mit dem Rest? Die Konfigurations-Sicherung ist ein Scherz, da dort nur die paar User und Gruppen-Infos, die man für Samba braucht, festgehalten werden. Ich hab zumindest in meiner Sicherungsdatei nicht viel mehr per Editor ausmachen können. Da ich nun schon ein wenig im Betriebssystem und den Diensten (Apache, MySQL usw.) herumgeändert habe, muss ich mehr sichern, damit im Falle des Neueinspielens des Betriebssystems nicht alles per Hand nachgearbeitet werden muss.
Sicherung von wichtigen Systemkonfigurationsdateien
Da es kein Backup für die Systempartition gibt (also Backup per dd wäre ja möglich, aber wie restort man das dann, wenn man keinen Lader hat, der das Image zurückspielt - oder kennt da jemand eine Lösung? Im Prinzip müsste das schon gehen, aber leider kenn ich mich in Linux-Box-Varianten net so gut aus), macht es Sinn, wenigstens die veränderten Dateien in einen gemeinsamen Samba-Ordner zu sichern. Die kann man, wenns Betriebssystem wieder drauf ist, ja locker zurückspielen (Dienste stoppen und wieder starten und alles läuft wie gehabt).
Also ein neues gemeinsames Ordnerchen (z.B. namens system) angelegt und folgendes Shell-Skript namens clone.sh dort hineingeschrieben:
if test -n "$2" -a -n "$1"
then
for i in $(find $1 -newer /usr/syno/apache/conf -print)
do
if test -d $i; then continue; fi
targetdir=$2$(dirname $i)
if test ! -d $targetdir
then
mkdir -p $targetdir
fi
echo cp $i $targetdir
cp $i $targetdir
done
else
echo " missing argument(s)"
echo " clone.sh source_dir target_dir"
fi
Das Skript 3 x aufrufen:
./clone.sh /etc /volume1/system
./clone.sh /etc.defaults /volume1/system
./clone.sh /usr /volume1/system
und schon hat man eine Kopie aller veränderten Dateien als Direktory-Struktur in seinem Verzeichnis, welches man nun wie gehabt irgendwie sichern kann (lokal auf USB, oder schlicht von Windows aus).
Anmerkungen:
(1) Ich habe nur in den 3 Verzeichnissen veränderte Konfigurationsdateien gefunden - da mag vielleicht bei dem ein oder anderen anders sein. Ein find-Aufruf schafft Klarheit.
(2) Ich vergleiche den Modifikations-Zeitstempel der Dateien mit dem des Verzeichnisses /usr/syno/apache/conf. Das ist pure Willkür. Dieses Verzeichnis ist 2 Minuten jünger als die restliche Installation und gibt als Referenzzeit eine gute Zeitvorgabe. Leider kann man die Zeit nicht Minuten-genau 'unserer' find-Version mitteilen (und das touch-Kommando kennt leider auch nicht die Modifikation auf eine angegeben Zeit, wie sonst üblich, sonst könnte man sich den Zeitstempel für die Referenz selbst beschaffen). Ich habe so ca. 80 Dateien (= 100kb) auf diese Weise gesichert. Ein Blick über die Dateinamen zeigt, dass es auf jeden Fall die von mir modifizierten sind und noch ein paar mehr
Sicherung der MySQL-Datenbank-Dateien
Nun bleibt noch meine MySQL-Datenbank zu sichern. Da die recht groß ist (rund 5 GB) sind die üblichen SQL-Anweisungen nicht sonderlich performant. Besser ist, wenn man die (sind Dateien, die die Datenbank angelegt hat, direkt sichert. Dazu muss man erst einmal den MySQL-Server runterfahren (wie auch immer, dazu gibts ein Systemskript unter /usr/syno/etc/rc.d:
S21mysql.sh stop
analog dazu kann man später auch wieder starten mit: S21mysql.sh start
Dann braucht man einen gemeinsamen Ordner, z.B. db.
Nun ändert man per vi (nachdem man vorher eine Kopie gemacht hat) die Datei /usr/syno/etc/smb.conf. Der Abschnitt [db] wird geändet in [@database] und innerhalb des Abschnitts wird auch der Pfad geändert: path=/volume1/@database
Änderung gespeichert und schon sieht man im Windows-Explorer das neue Verziechnis @database und kann das nun irgendwohin sichern. Leider erscheint das Verzeichnis nicht im Disk Station Manger für eine lokale Sicherung ... daran arbeite ich noch, wenn jemand einen Tipp hat, bitte erzählen. Aber man hat zumindest schon mal eine Möglichkeit für die Datenbanksicherung auf physikalischer Ebene.
hab die 207+ erst seit Mitte des Monats und natürlich noch ganz viele Flausen im Kopf, was man mit dem Ding anstellen kann. Da mittlerweile mein RAID1 schon zweimal herhalten musste (neue Synchronisation), mach ich mir schon Gedanken, was passieren wird, wenn beide Platten sich nicht mehr rühren
Hab hier im Forum ein wenig herum geschmöckert und festgestellt, dass es wohl auch berechtigt ist, sich Gedanken zur Datensicherung zu machen. Klar, die 'gemeinsamen' Ordner kann man locker sichern. Aber was macht man mit dem Rest? Die Konfigurations-Sicherung ist ein Scherz, da dort nur die paar User und Gruppen-Infos, die man für Samba braucht, festgehalten werden. Ich hab zumindest in meiner Sicherungsdatei nicht viel mehr per Editor ausmachen können. Da ich nun schon ein wenig im Betriebssystem und den Diensten (Apache, MySQL usw.) herumgeändert habe, muss ich mehr sichern, damit im Falle des Neueinspielens des Betriebssystems nicht alles per Hand nachgearbeitet werden muss.
Sicherung von wichtigen Systemkonfigurationsdateien
Da es kein Backup für die Systempartition gibt (also Backup per dd wäre ja möglich, aber wie restort man das dann, wenn man keinen Lader hat, der das Image zurückspielt - oder kennt da jemand eine Lösung? Im Prinzip müsste das schon gehen, aber leider kenn ich mich in Linux-Box-Varianten net so gut aus), macht es Sinn, wenigstens die veränderten Dateien in einen gemeinsamen Samba-Ordner zu sichern. Die kann man, wenns Betriebssystem wieder drauf ist, ja locker zurückspielen (Dienste stoppen und wieder starten und alles läuft wie gehabt).
Also ein neues gemeinsames Ordnerchen (z.B. namens system) angelegt und folgendes Shell-Skript namens clone.sh dort hineingeschrieben:
if test -n "$2" -a -n "$1"
then
for i in $(find $1 -newer /usr/syno/apache/conf -print)
do
if test -d $i; then continue; fi
targetdir=$2$(dirname $i)
if test ! -d $targetdir
then
mkdir -p $targetdir
fi
echo cp $i $targetdir
cp $i $targetdir
done
else
echo " missing argument(s)"
echo " clone.sh source_dir target_dir"
fi
Das Skript 3 x aufrufen:
./clone.sh /etc /volume1/system
./clone.sh /etc.defaults /volume1/system
./clone.sh /usr /volume1/system
und schon hat man eine Kopie aller veränderten Dateien als Direktory-Struktur in seinem Verzeichnis, welches man nun wie gehabt irgendwie sichern kann (lokal auf USB, oder schlicht von Windows aus).
Anmerkungen:
(1) Ich habe nur in den 3 Verzeichnissen veränderte Konfigurationsdateien gefunden - da mag vielleicht bei dem ein oder anderen anders sein. Ein find-Aufruf schafft Klarheit.
(2) Ich vergleiche den Modifikations-Zeitstempel der Dateien mit dem des Verzeichnisses /usr/syno/apache/conf. Das ist pure Willkür. Dieses Verzeichnis ist 2 Minuten jünger als die restliche Installation und gibt als Referenzzeit eine gute Zeitvorgabe. Leider kann man die Zeit nicht Minuten-genau 'unserer' find-Version mitteilen (und das touch-Kommando kennt leider auch nicht die Modifikation auf eine angegeben Zeit, wie sonst üblich, sonst könnte man sich den Zeitstempel für die Referenz selbst beschaffen). Ich habe so ca. 80 Dateien (= 100kb) auf diese Weise gesichert. Ein Blick über die Dateinamen zeigt, dass es auf jeden Fall die von mir modifizierten sind und noch ein paar mehr
Sicherung der MySQL-Datenbank-Dateien
Nun bleibt noch meine MySQL-Datenbank zu sichern. Da die recht groß ist (rund 5 GB) sind die üblichen SQL-Anweisungen nicht sonderlich performant. Besser ist, wenn man die (sind Dateien, die die Datenbank angelegt hat, direkt sichert. Dazu muss man erst einmal den MySQL-Server runterfahren (wie auch immer, dazu gibts ein Systemskript unter /usr/syno/etc/rc.d:
S21mysql.sh stop
analog dazu kann man später auch wieder starten mit: S21mysql.sh start
Dann braucht man einen gemeinsamen Ordner, z.B. db.
Nun ändert man per vi (nachdem man vorher eine Kopie gemacht hat) die Datei /usr/syno/etc/smb.conf. Der Abschnitt [db] wird geändet in [@database] und innerhalb des Abschnitts wird auch der Pfad geändert: path=/volume1/@database
Änderung gespeichert und schon sieht man im Windows-Explorer das neue Verziechnis @database und kann das nun irgendwohin sichern. Leider erscheint das Verzeichnis nicht im Disk Station Manger für eine lokale Sicherung ... daran arbeite ich noch
, wenn jemand einen Tipp hat, bitte erzählen. Aber man hat zumindest schon mal eine Möglichkeit für die Datenbanksicherung auf physikalischer Ebene.
