Hallo! Ich möchte mir eine Art Linuxtestsystem aufbauen, wo ich unter anderen auch mit Software herumspielen kann, ohne mein Hauptsystem zu zerschießen. Um bei größeren Problemen nicht immer alles neu installieren zu müssen, wollte ich mir zwei Parttitionen anlegen, wo auf einer das Testsystem ist und auf der zweiten ein Abbild desselben Systems vor dem Einspielen des aktuellen Packages, um so bei Problemen recht schnell wieder ein Basissystem zurückzuhaben. Da auf der Platte noch ein anderes Linuxsystem, nämlich mein "Produktivsystem" ist, wollte ich hier eigentlich so vorgehen, daß ich mich einlogge, die beiden Partitionen mounte und dann einfach mit cp -r das eine auf das andere verschiebe. Geht das einfach so? Oder muß ich hier etwas beachten? Da dies auch etwas länger mit cp -r dauern kann, gibt es ggf. alternative Programme, die hier besser geeignet wären? Danke! G. Daniel -- The most beautiful thing we can experience is the mysterious, It is the source of all true art and science. A. Einstein, What I Believe http://www.student.informatik.tu-darmstadt.de/~ludwig
Am Sonntag, 3. Juni 2001 15:35 schrieb Daniel Ludwig:
mit cp -r das eine auf das andere verschiebe.
Geht das einfach so? Oder muß ich hier etwas beachten? Da dies auch etwas länger mit cp -r dauern kann, gibt es ggf. alternative Programme, die hier besser geeignet wären?
Ich bin kein Backup-Experte, aber so geht das sicher _nicht_. Zumindest nicht, wenn Du eine zweite bootfähig Platte haben willst, die Du bei Bedarf anstelle der ersten booten kannst. Eine Möglichkeit wäre, das System von CD zu booten und dann die Platten, wenn sie hardwaremäßig identisch sind, mittels dd zu kopieren, z.B.: dd if=/dev/hda of=/dev/hdb Dabei kannst Du zusätzlich noch etwas mit dem bs Parameter rumspielen, der evtl. Einfluß auf die Performance hat. Ciao, Matthias
Am Son, 03 Jun 2001 schrieb Matthias Kleine:
Am Sonntag, 3. Juni 2001 15:35 schrieb Daniel Ludwig:
mit cp -r das eine auf das andere verschiebe.
Geht das einfach so? Oder muß ich hier etwas beachten? Da dies auch etwas länger mit cp -r dauern kann, gibt es ggf. alternative Programme, die hier besser geeignet wären?
Ich bin kein Backup-Experte, aber so geht das sicher _nicht_. Zumindest nicht, wenn Du eine zweite bootfähig Platte haben willst, die Du bei Bedarf anstelle der ersten booten kannst.
Nein, nein, so ist das nicht. Es gibt im System eine großzügig bemessene Bootpartition, wo die einzelnen Kernels sind. Lediglich das / -Verzeichnis muß gespiegelt werden, und auch das ohne /home, da das eine weitere Partition ist. Danke! G. Daniel -- The most beautiful thing we can experience is the mysterious, It is the source of all true art and science. A. Einstein, What I Believe http://www.student.informatik.tu-darmstadt.de/~ludwig
Daniel Ludwig wrote:
Am Son, 03 Jun 2001 schrieb Matthias Kleine:
Am Sonntag, 3. Juni 2001 15:35 schrieb Daniel Ludwig:
mit cp -r das eine auf das andere verschiebe.
Geht das einfach so? Oder muß ich hier etwas beachten? Da dies auch etwas länger mit cp -r dauern kann, gibt es ggf. alternative Programme, die hier besser geeignet wären?
Ich bin kein Backup-Experte, aber so geht das sicher _nicht_. Zumindest nicht, wenn Du eine zweite bootfähig Platte haben willst, die Du bei Bedarf anstelle der ersten booten kannst.
Nein, nein, so ist das nicht. Es gibt im System eine großzügig bemessene Bootpartition, wo die einzelnen Kernels sind. Lediglich das / -Verzeichnis muß gespiegelt werden, und auch das ohne /home, da das eine weitere Partition ist.
Mit einem einzigen cp -r / /mnt/bla geht's sicher nicht. Wenn Du aber die Verzeichnisse selektiv kopierst, geht es prinzipiell. /proc, /boot, /dev, /mnt können/dürfen/sollten nicht mit kopiert werden. Bei /var und /etc wird es schwierig. Je nachdem was Du vorhast, ist es sinnvoll, aus /var einzelne Verzeichnisse mitzukopieren oder auch nicht (Insb. RPM-Datenbank, Spooling/Working-Areas der Daemons (named/yp/mail)). Unter /etc können einige Dateien übernommen werden (z.B. passwd), einige nicht (z.B. fstab), einige müssen es (z.B. lilo.conf) Vermutlich ist es aber einfacher, gleich zwei unabhängige Installationen (mit ge-shared-ter /boot) einzurichten, und dann die wichtigsten Files mit einem Script abzugleichen. Ralf.
Am Son, 03 Jun 2001 schrieb Ralf Corsepius:
Daniel Ludwig wrote:
Nein, nein, so ist das nicht. Es gibt im System eine großzügig bemessene Bootpartition, wo die einzelnen Kernels sind. Lediglich das / -Verzeichnis muß gespiegelt werden, und auch das ohne /home, da das eine weitere Partition ist. Mit einem einzigen cp -r / /mnt/bla geht's sicher nicht.
Wenn Du aber die Verzeichnisse selektiv kopierst, geht es prinzipiell. /proc, /boot, /dev, /mnt können/dürfen/sollten nicht mit kopiert werden. Bei /var und /etc wird es schwierig. Je nachdem was Du vorhast, ist es sinnvoll, aus /var einzelne Verzeichnisse mitzukopieren oder auch nicht (Insb. RPM-Datenbank, Spooling/Working-Areas der Daemons (named/yp/mail)). Unter /etc können einige Dateien übernommen werden (z.B. passwd), einige nicht (z.B. fstab), einige müssen es (z.B. lilo.conf)
Ich möchte mich einfach absichern, daß, falls bei einer Installation etwas schiefgeht, ich nicht gleich alles wieder neu installieren muß und dadurch auch alle bisherigen Installationen verliere, sondern mit einem schnellen cp ...... diese zerstörte Installation durch eine korrekte ersetze, um es erneut zu versuchen. Klappt die Installation gut, will ich sie wieder als Basis für die nächste Aktion nutzen, also auf die Sicherheitspartition kopieren. Da müßte schon /var und /etc mitgehen. Wie gesagt, die Aktion soll nicht aus einem der beiden Systeme, sondern aus meinem Produktivsystem gestartet werden. Daher dürften auch /proc etc mitgehen, oder? G. Daniel -- The most beautiful thing we can experience is the mysterious, It is the source of all true art and science. A. Einstein, What I Believe http://www.student.informatik.tu-darmstadt.de/~ludwig
* Daniel Ludwig schrieb am 03.Jun.2001:
Ich möchte mich einfach absichern, daß, falls bei einer Installation etwas schiefgeht, ich nicht gleich alles wieder neu installieren muß und dadurch auch alle bisherigen Installationen verliere, sondern mit einem schnellen cp ...... diese zerstörte Installation durch eine korrekte ersetze, um es erneut zu versuchen. Klappt die Installation gut, will ich sie wieder als Basis für die nächste Aktion nutzen, also auf die Sicherheitspartition kopieren. Da müßte schon /var und /etc mitgehen. Wie gesagt, die Aktion soll nicht aus einem der beiden Systeme, sondern aus meinem Produktivsystem gestartet werden. Daher dürften auch /proc etc mitgehen, oder?
Nimm cp -ax Siehe man cp. -a entspricht -dpR, dadurch werden die Rechte richtig gesetzt und ein Symlink gesetzt, wo ein Symlink hingehört. Durch -x werden andere Dateisysteme nicht mitkopiert. Nein, /proc brauch und soll nicht mitkopiert werden. /proc ist ein eigenes (Pseudo-)Dateisystem. /proc liegt nicht auf Festplatte, sondern im Hauptspeicher. Bernd -- Probleme mit dem Drucker? Schon die Druckercheckliste beachtet? http://localhost/doc/sdb/de/html/drucker-howto.html | Auch lesenswert: Oder schon das Drucker-HOWTO gelesen? | man lpr file://usr/shar/doc/howto/de/DE-Drucker-HOWTO.txt.gz | Zufallssignatur 3
Hi
ich glaube der Befehl um die Bootpartion des Kernel zu ändern heist rdev
aber es geht auch im lilo-prompt als Parameter /dev/hdxy
gruss
Markus
----- Original Message -----
From: "Matthias Kleine"
Am Sonntag, 3. Juni 2001 15:35 schrieb Daniel Ludwig:
mit cp -r das eine auf das andere verschiebe.
Geht das einfach so? Oder muß ich hier etwas beachten? Da dies auch etwas länger mit cp -r dauern kann, gibt es ggf. alternative Programme, die hier besser geeignet wären?
Ich bin kein Backup-Experte, aber so geht das sicher _nicht_. Zumindest nicht, wenn Du eine zweite bootfähig Platte haben willst, die Du bei Bedarf anstelle der ersten booten kannst.
Eine Möglichkeit wäre, das System von CD zu booten und dann die Platten, wenn sie hardwaremäßig identisch sind, mittels dd zu kopieren, z.B.:
dd if=/dev/hda of=/dev/hdb
Dabei kannst Du zusätzlich noch etwas mit dem bs Parameter rumspielen, der evtl. Einfluß auf die Performance hat.
Ciao, Matthias
--------------------------------------------------------------------- To unsubscribe, e-mail: suse-linux-unsubscribe@suse.com For additional commands, e-mail: suse-linux-help@suse.com
Am Sonntag, 3. Juni 2001 15:35 schrieb Daniel Ludwig:
Hallo!
Ich möchte mir eine Art Linuxtestsystem aufbauen, wo ich unter anderen auch mit Software herumspielen kann, ohne mein Hauptsystem zu zerschießen. Um bei größeren Problemen nicht immer alles neu installieren zu müssen, wollte ich mir zwei Parttitionen anlegen, wo auf einer das Testsystem ist und auf der zweiten ein Abbild desselben Systems vor dem Einspielen des aktuellen Packages, um so bei Problemen recht schnell wieder ein Basissystem zurückzuhaben. Da auf der Platte noch ein anderes Linuxsystem, nämlich mein "Produktivsystem" ist, wollte ich hier eigentlich so vorgehen, daß ich mich einlogge, die beiden Partitionen mounte und dann einfach mit cp -r das eine auf das andere verschiebe.
Geht das einfach so? Oder muß ich hier etwas beachten? Da dies auch etwas länger mit cp -r dauern kann, gibt es ggf. alternative Programme, die hier besser geeignet wären?
Es gibt so ein Prog heisst Partition Image du kannst damit deine Partitionen imagen und wenn du mal irgendwas zeschoßen hast kannst du es "zurückspullen". www.partimage.org hab noch nicht probiert. cu roman
--Am Sonntag, Juni 03, 2001 15:35:33 +0200 schrieb Daniel Ludwig
Hallo!
Ich möchte mir eine Art Linuxtestsystem aufbauen, wo ich unter anderen auch mit Software herumspielen kann, ohne mein Hauptsystem zu zerschießen. Um bei größeren Problemen nicht immer alles neu installieren zu müssen, wollte ich mir zwei Parttitionen anlegen, wo auf einer das Testsystem ist und auf der zweiten ein Abbild desselben Systems vor dem Einspielen des aktuellen Packages, um so bei Problemen recht schnell wieder ein Basissystem zurückzuhaben. Da auf der Platte noch ein anderes Linuxsystem, nämlich mein "Produktivsystem" ist, wollte ich hier eigentlich so vorgehen, daß ich mich einlogge, die beiden Partitionen mounte und dann einfach mit cp -r das eine auf das andere verschiebe.
Geht das einfach so? Oder muß ich hier etwas beachten?
Du solltest cp -dpR benutzen. Du solltest nicht den Inhalt von Verzeichnissen kopieren, wo eine andere Partition eingehängt ist z.B. /boot. Du solltest nicht /proc mitkopieren, sonst könnte deine 2 Partition recht schnell vollaufen :-)
Da dies auch etwas länger mit cp -r dauern kann, gibt es ggf. alternative Programme, die hier besser geeignet wären?
tar aber ob das schneller ist dabei weiß ich nicht, zumindest
kannst Du Pfade mit angeben, die nicht mitkopiert werden sollen.
Das Gleiche gilt für rsync (das könntest Du aber später zum
abgleichen von Änderungen verwenden.
Dirk
--
Dirk Hartmann
Hi Daniel, schau mal unter http://sdb.suse.de/sdb/de/html/maddin_kopieren.html Ich denke, das sollte für deine Zwecke ausreichen, oder? Schau dir hierzu auch mal den Thread "Festplatte kopieren" vom 1.6. an. Darin wird auch beschrieben was der Befehl bedeutet; Danke nochmal :-)) event kannst du dann auch einfach ein tar-Archiv anlegen in der du hin und wieder heine Konfiguratin sicherst und wenn mal was schief geht spielst du das Archiv zurück. CU Stefan
Hallo! Ich möchte mir eine Art Linuxtestsystem aufbauen, wo ich unter anderen auch mit Software herumspielen kann, ohne mein Hauptsystem zu zerschießen. Um bei größeren Problemen nicht immer alles neu installieren zu müssen, wollte ich mir zwei Parttitionen anlegen, wo auf einer das Testsystem ist und auf der zweiten ein Abbild desselben Systems vor dem Einspielen des aktuellen Packages, um so bei Problemen recht schnell wieder ein Basissystem zurückzuhaben. Da auf der Platte noch ein anderes Linuxsystem, nämlich mein "Produktivsystem" ist, wollte ich hier eigentlich so vorgehen, daß ich mich einlogge, die beiden Partitionen mounte und dann einfach mit cp -r das eine auf das andere verschiebe. Geht das einfach so? Oder muß ich hier etwas beachten? Da dies auch etwas länger mit cp -r dauern kann, gibt es ggf. alternative Programme, die hier besser geeignet wären? Hallo Wenn du zwei Platten hast, kann ich dir einen script anbieten der den System von einer Platte auf die andere Spiegelt mit cron. Ich lasse diesen script täglich laufen. Du kannst dann beim booten wählen welche Platte du gebootet haben willst. Gruß Jens
----- Original Message -----
From: "Jens Frederich"
Hallo!
Ich möchte mir eine Art Linuxtestsystem aufbauen, wo ich unter anderen auch mit Software herumspielen kann, ohne mein Hauptsystem zu zerschießen. Um bei größeren Problemen nicht immer alles neu installieren zu müssen, wollte ich mir zwei Parttitionen anlegen, wo auf einer das Testsystem ist und auf der zweiten ein Abbild desselben Systems vor dem Einspielen des aktuellen Packages, um so bei Problemen recht schnell wieder ein Basissystem zurückzuhaben. Da auf der Platte noch ein anderes Linuxsystem, nämlich mein "Produktivsystem" ist, wollte ich hier eigentlich so vorgehen, daß ich mich einlogge, die beiden Partitionen mounte und dann einfach mit cp -r das eine auf das andere verschiebe.
Geht das einfach so? Oder muß ich hier etwas beachten? Da dies auch etwas länger mit cp -r dauern kann, gibt es ggf. alternative Programme, die hier besser geeignet wären?
Hallo Wenn du zwei Platten hast, kann ich dir einen script anbieten der den
System
von einer Platte auf die andere Spiegelt mit cron. Ich lasse diesen script täglich laufen. Du kannst dann beim booten wählen welche Platte du gebootet haben willst. Hallo, Entschuldigung ich habe das Quoting vergessen. Danke für den Hinweis Jan. Hier noch einmal mein Text.
Hallo Wenn du zwei Platten hast, kann ich dir einen script anbieten der den System von einer Platte auf die andere Spiegelt mit cron. Ich lasse diesen script täglich laufen. Du kannst dann beim booten wählen welche Platte du gebootet haben willst. Gruß Jens
Hallo Jens, * Jens Frederich schlug in die Tasten:
Wenn du zwei Platten hast, kann ich dir einen script anbieten der den System von einer Platte auf die andere Spiegelt mit cron. Ich lasse diesen script täglich laufen. Du kannst dann beim booten wählen welche Platte du gebootet haben willst.
Dieses Skript würde mich auch brennend interessieren, zumal ich hier einen Server betreibe und den Inhalt meiner Festplatte spiegeln will. Ich hab dazu eine 2. Festplatte. Ich such nämlich nach einer Lösung, wie ich am besten täglich meine Platte auf die andere kopieren kann. Ich bin auch die vorherigen Threads durchgegangen, weiss aber noch nicht, was für meine Zwecke am besten ist. Vor allem soll die automatische Sicherung in laufenden Betrieb erfolgen. Aber wie ist es, wenn Programme und Prozesse im Hintergrund laufen? Hat das negativen Einfluss beim Kopieren? Ich denke, zumindest müssen alle Anwendungen geschlossen sein, oder nicht? Jedenfalls danke in Voraus -- Written with mutt 1.2.5 under Debian/GNU Linux 2.2r3 .... :-) Greetings Alex Registered Linux User #169741
--Am Dienstag, Juni 05, 2001 07:46:58 +0200 schrieb Zeimet Alex
Dieses Skript würde mich auch brennend interessieren, zumal ich hier einen Server betreibe und den Inhalt meiner Festplatte spiegeln will. Ich hab dazu eine 2. Festplatte. Ich such nämlich nach einer Lösung, wie ich am besten täglich meine Platte auf die andere kopieren kann.
rsync
Ich bin auch die vorherigen Threads durchgegangen, weiss aber noch nicht, was für meine Zwecke am besten ist. Vor allem soll die automatische Sicherung in laufenden Betrieb erfolgen.
rsync
Aber wie ist es, wenn Programme und Prozesse im Hintergrund laufen? Hat das negativen Einfluss beim Kopieren? Ich denke, zumindest müssen alle Anwendungen geschlossen sein, oder nicht?
wir sind doch nicht bei Windows :-)
Dirk
--
Dirk Hartmann
Am Dienstag, 5. Juni 2001 19:10 schrieb Dirk Hartmann:
--Am Dienstag, Juni 05, 2001 07:46:58 +0200 schrieb Zeimet Alex
Aber wie ist es, wenn Programme und Prozesse im Hintergrund laufen? Hat das negativen Einfluss beim Kopieren? Ich denke, zumindest müssen alle Anwendungen geschlossen sein, oder nicht?
wir sind doch nicht bei Windows :-)
Das stimmt jedoch hier nicht so ganz: Wenn er ein System spiegeln will, macht es Sinn dafür zu sorgen, dass das System in einem "korrekten" Zustand ist. Er will also einen bestimmten Zeitpunkt spiegeln. Und da macht es durchaus Sinn zu verhindern, dass andere Programme an diesem Zustand rumfummeln. Er sollte sich also zumindest überlegen, welche Programme da noch arbeiten ... Heiner -- Heiner Lamprecht Philosophenweg 79 D - 72076 Tuebingen Fon: +49-7071-600 162 Fax: +49-7071-600 164 heiner@kflog.de GnuPG - Key: E05AEAFC Fingerprint: 257A DFBF 4977 4585 77A0 3509 973B 92AA E05A EAFC
Heiner Lamprecht schrieb am Die, 05 Jun 2001:
Am Dienstag, 5. Juni 2001 19:10 schrieb Dirk Hartmann:
--Am Dienstag, Juni 05, 2001 07:46:58 +0200 schrieb Zeimet Alex
Aber wie ist es, wenn Programme und Prozesse im Hintergrund laufen? Hat das negativen Einfluss beim Kopieren? Ich denke, zumindest müssen alle Anwendungen geschlossen sein, oder nicht?
wir sind doch nicht bei Windows :-)
Das stimmt jedoch hier nicht so ganz:
Wenn er ein System spiegeln will, macht es Sinn dafür zu sorgen, dass das System in einem "korrekten" Zustand ist. Er will also einen bestimmten Zeitpunkt spiegeln. Und da macht es durchaus Sinn zu verhindern, dass andere Programme an diesem Zustand rumfummeln. Er sollte sich also zumindest überlegen, welche Programme da noch arbeiten ...
ACK. Habe bei mir nen cronjob eingerichtet, so dass jeden Tag um 17.30 Uhr das Home-Verzeichnis auf ne zweite Platte gesichert wird. Wenn ich zu dem Zeitpunkt allerdings gerade mit meinen bug-belasteten Kmail (Hallo David ;-) ne E-Mail an die Liste schreibe oder speichern will produziert das jede Menge Fehlermeldungen in var/log/messages a la file xy:could not write to /backup on ... Seit dem ich das ein paar mal mitgemacht habe versuche ich tunlichst um 17.30 die Finger von meinem PC zu lassen. cu Manfred -- Registered Linux-User #216556 http://counter.li.org./ ******************************************* In a World without Walls and Fences, who needs Windows and Gates? *******************************************
On Die, Jun 05, 2001 at 08:38:01 +0200, Manfred Misch wrote:
Heiner Lamprecht schrieb am Die, 05 Jun 2001: [...]
Wenn er ein System spiegeln will, macht es Sinn dafür zu sorgen, dass das System in einem "korrekten" Zustand ist. Er will also einen bestimmten Zeitpunkt spiegeln. Und da macht es durchaus Sinn zu verhindern, dass andere Programme an diesem Zustand rumfummeln. Er sollte sich also zumindest überlegen, welche Programme da noch arbeiten ...
ACK. Habe bei mir nen cronjob eingerichtet, so dass jeden Tag um 17.30 Uhr das Home-Verzeichnis auf ne zweite Platte gesichert wird. Wenn ich zu dem Zeitpunkt allerdings gerade mit meinen bug-belasteten Kmail (Hallo David ;-) ne E-Mail an die Liste schreibe oder speichern will produziert das jede Menge Fehlermeldungen in var/log/messages a la file xy:could not write to /backup on ... Seit dem ich das ein paar mal mitgemacht habe versuche ich tunlichst um 17.30 die Finger von meinem PC zu lassen.
Ist das ein Client, den Du nach dem Arbeiten runterfährst? Dann wäre der shutdown ein prima Zeitpunkt für eine Spiegelung (wenns nicht zuviel Zeit braucht), dann arbeitet nämlich keiner mehr ;-) Ich habe mir meine Client-Backups so eingerichtet, mache allerdings auch keine Vollsicherung. Jan
Jan Trippler schrieb am Die, 05 Jun 2001:
Ist das ein Client, den Du nach dem Arbeiten runterfährst? Dann wäre der shutdown ein prima Zeitpunkt für eine Spiegelung (wenns nicht zuviel Zeit braucht), dann arbeitet nämlich keiner mehr ;-) Ich habe mir meine Client-Backups so eingerichtet, mache allerdings auch keine Vollsicherung.
Na ich noch recht unbedarft bin in Sachen "Linux" - wie geht das? Thx Manfred -- Registered Linux-User #216556 http://counter.li.org./ ******************************************* In a World without Walls and Fences, who needs Windows and Gates? *******************************************
On Don, Jun 07, 2001 at 08:50:34 +0200, Manfred Misch wrote:
Jan Trippler schrieb am Die, 05 Jun 2001:
Ist das ein Client, den Du nach dem Arbeiten runterfährst? Dann wäre der shutdown ein prima Zeitpunkt für eine Spiegelung (wenns nicht zuviel Zeit braucht), dann arbeitet nämlich keiner mehr ;-) Ich habe mir meine Client-Backups so eingerichtet, mache allerdings auch keine Vollsicherung.
Na ich noch recht unbedarft bin in Sachen "Linux" - wie geht das?
Es gibt viele Möglichkeiten ;-) Ich will jetzt keinen Vortrag über Backup-Strategien halten, deshalb nur ein paar Stichpunkte / Literaturquellen: Starten beim Shutdown: Du kannst eigentlich beliebige eigene Scripts basteln, die beim Wechseln der Runlevel ausgeführt werden. Da ich hier kein System > SuSE 6.2 am Laufen habe (und hier mit 7.x viele Änderungen erfolgten), verweise ich mal auf das Handbuch. Die Scripts liegen unter /etc/rc.d und Du kannst dort eigene reinhängen. Deltasicherungen: Es werden nur die Daten gesichert, die sich seit dem Zeitpunkt der letzten Sicherung geändert haben. Dies festzustellen ist mit verschiedenen Mitteln möglich: - modification time der Dateien (man ls, man touch); das ist aber ein wenig unsicher, da verschiedene Befehle (touch, tar, cpio, cp, mv) Zeitstempel bei neu in den Sicherungsbereich gestellten Dateien manipulieren können. - Mit mehr Aufwand: Bilden von Checksummen über die Dateiinhalte; Hier sollte man mehrere Verfahren kombinieren (ich nutze z. B. md5sum und die Dateigröße), weil da ein Restrisiko besteht ... - Eine Datei, die von Verzeichnis a nach Verzeichnis b verschoben wurde, muss nicht nochmal gesichert werden, wenn man die Verzeichnisstruktur getrennt von den Dateiinhalten sichert. Ich packe die Strukturen (inkl. der Stati von Devices usw.) in extra Dateien und sichere nur geänderte Dateien unter ihrer md5sum. Dies kombiniert mit einer Generationssicherung (Level 0, 1, 2 oder Großvater-, Vater-, Sohn-Prinzip) reduziert die zu sichernden Datenmengen drastisch. Generationssicherung bedeutet, dass jedes höhere Level nur die Änderungen sichert, die seit der letzten Sicherung mit gleichem oder niedrigeren Level geändert wurden, in zu definierenden Abständen dazwischen eine Vollsicherung (um die Anzahl der zu rekonstruierenden Datenträger in überschaubaren Mengen zu halten): Beispiel 1: Am 1. des Monats eine Vollsicherung (Level 0) Jeden Freitag eine Level 1 Sicherung (alle Deltas zum letzten Level 0 / Level 1) Täglich eine Level 2 Sicherung (Änderungen zum letzten Level 1 / Level 2) Im ungünstigsten Fall restaurierst Du: Level 0 4 x Level 1 4 x Level 2 jedoch sind die Sicherungsmengen hier sehr gering (Level 2 nur Änderungen eines Tages). Beispiel 2: Kumulierende Deltasicherung: Am 1. des Monats eine Vollsicherung (Level 0) Jeden Freitag eine Level 1 Sicherung (alle Deltas zum letzten Level 0) Täglich eine Level 2 Sicherung (Änderungen zum letzten Level 1) Im ungünstigsten Fall restaurierst Du: Level 0 1 x Level 1 1 x Level 2 Dafür wachsen die Sicherungsmengen mit jeder Sicherung an, weil Du hier immer auf den nächstniedrigeren Level sicherst. Es gibt etliche andere Verfahren, wichtig ist hier immer das Abschätzen des Aufwandes beim Sichern zu dem beim Rekonstruieren. Die tollste Deltasicherung nützt Dir gar nichts, wenn sich die wichtigen Daten alle in einer Riesen-Datenbankdatei befinden. Dann kannst Du gleich alles sichern. Einschränken der zu sichernden Bereiche: Viele Verzeichnisse (vor allem in den /bin, /usr-Bereichen) brauchen eh nur dann gesichert zu werden, wenn z .B. Software neu installiert wurde. Sowas lasse ich weg, da kann man auch von CD neu installieren. So, Ende des Ausflugs Jan
Jan Trippler
Ist das ein Client, den Du nach dem Arbeiten runterfährst? Dann wäre der shutdown ein prima Zeitpunkt für eine Spiegelung (wenns nicht zuviel Zeit braucht), dann arbeitet nämlich keiner mehr ;-) Ich habe mir meine Client-Backups so eingerichtet, mache allerdings auch keine Vollsicherung.
Na ich noch recht unbedarft bin in Sachen "Linux" - wie geht das?
Es gibt viele Möglichkeiten ;-) Ich will jetzt keinen Vortrag über Backup-Strategien halten, deshalb nur ein paar Stichpunkte / Literaturquellen: [...]
Ho, Brauner, ho ;-))) Bevor mit Dir die Pferde durchgehen - das war nicht meine Absicht. Backup-Strategien kenn ich zuhauf, aber mit geht es als "unbedarfter" Linuxneuling mehr um den Inhalt des Scriptes, dass die Datensicherung beim Shutdown startet. Ich bin nämlich auch noch seeehr "unbedarft" im Schreiben von "brauchbaren" Scripten ;-))). Falls das jedoch jetzt zu sehr in´s Detail geht, kannst Du mir ja auch vielleicht per PM ein bisschen weiterhelfen. Thx a lot Manfred
--Am Dienstag, Juni 05, 2001 20:38:01 +0200 schrieb Manfred Misch
Heiner Lamprecht schrieb am Die, 05 Jun 2001:
Am Dienstag, 5. Juni 2001 19:10 schrieb Dirk Hartmann:
--Am Dienstag, Juni 05, 2001 07:46:58 +0200 schrieb Zeimet Alex
Aber wie ist es, wenn Programme und Prozesse im Hintergrund laufen? Hat das negativen Einfluss beim Kopieren? Ich denke, zumindest müssen alle Anwendungen geschlossen sein, oder nicht?
wir sind doch nicht bei Windows :-)
Das stimmt jedoch hier nicht so ganz:
Wenn er ein System spiegeln will, macht es Sinn dafür zu sorgen, dass das System in einem "korrekten" Zustand ist. Er will also einen bestimmten Zeitpunkt spiegeln. Und da macht es durchaus Sinn zu verhindern, dass andere Programme an diesem Zustand rumfummeln. Er sollte sich also zumindest überlegen, welche Programme da noch arbeiten ...
ACK. Habe bei mir nen cronjob eingerichtet, so dass jeden Tag um 17.30 Uhr das Home-Verzeichnis auf ne zweite Platte gesichert wird. Wenn ich zu dem Zeitpunkt allerdings gerade mit meinen bug-belasteten Kmail (Hallo David ;-) ne E-Mail an die Liste schreibe oder speichern will produziert das jede Menge Fehlermeldungen in var/log/messages a la file xy:could not write to /backup on ... Seit dem ich das ein paar mal mitgemacht habe versuche ich tunlichst um 17.30 die Finger von meinem PC zu lassen.
Also ich habe mehrere Sicherheitskopien mit rsync laufen. Dabei
gibt es keine Probleme. Die Dateien werden halt im gerade
vorhandenen Zustand gespiegelt. Wenn das zu Fehlermeldungen führt,
stimmt irgendwas mit dem Filelocking nicht.
Aber bei den angesprochenen KDE-Dateien handelt es sich eh bloß um
Temporärdateien, die nicht wichtig sind. (Sowas kann man bei rsync
ausklammern)
Dirk
--
Dirk Hartmann
um deine festplatte im laufendem betrieb zu sichern, benutze das
raid+boot+lilo+raid howto. da steht alles drin und es funktioniert
einwandfrei.
http://ldp.accu.com/HOWTO/Boot+Root+Raid+LILO.html
was du brauchst sind aktuelle raidtools und Kernel 2.2.18<. (SuSE Linux 7.1
ist alles dabei, eig keine updates nötig um raid1 zu fahren.
viel spass
mfg
ph. trolliet
-----Original Message-----
From: Dirk Hartmann [mailto:hartm@web.de]
Sent: Dienstag, 5. Juni 2001 19:10
To: suse-linux@suse.com
Subject: Re: Spiegeln der Platte
--Am Dienstag, Juni 05, 2001 07:46:58 +0200 schrieb Zeimet Alex
Dieses Skript würde mich auch brennend interessieren, zumal ich hier einen Server betreibe und den Inhalt meiner Festplatte spiegeln will. Ich hab dazu eine 2. Festplatte. Ich such nämlich nach einer Lösung, wie ich am besten täglich meine Platte auf die andere kopieren kann.
rsync
Ich bin auch die vorherigen Threads durchgegangen, weiss aber noch nicht, was für meine Zwecke am besten ist. Vor allem soll die automatische Sicherung in laufenden Betrieb erfolgen.
rsync
Aber wie ist es, wenn Programme und Prozesse im Hintergrund laufen? Hat das negativen Einfluss beim Kopieren? Ich denke, zumindest müssen alle Anwendungen geschlossen sein, oder nicht?
wir sind doch nicht bei Windows :-)
Dirk
--
Dirk Hartmann
--Am Mittwoch, Juni 06, 2001 07:28:16 +0200 schrieb Philippe
Trolliet
um deine festplatte im laufendem betrieb zu sichern, benutze das raid+boot+lilo+raid howto. da steht alles drin und es funktioniert einwandfrei. http://ldp.accu.com/HOWTO/Boot+Root+Raid+LILO.html was du brauchst sind aktuelle raidtools und Kernel 2.2.18<. (SuSE Linux 7.1 ist alles dabei, eig keine updates nötig um raid1 zu fahren. viel spass mfg ph. trolliet
:-) viel mir eigentlich auch als Erstes ein, ein RAID1 zu machen,
aber er hatte ja explizit nach einmaligem täglichem Kopieren
gefragt.
Dirk
--
Dirk Hartmann
participants (15)
-
Bernd Brodesser -
Daniel Ludwig -
Dirk Hartmann -
ESG-M.Misch＠t-online.de -
Heiner Lamprecht -
Jan.Trippler＠t-online.de -
Jens Frederich -
Manfred Misch -
Markus Schumacher -
Matthias Kleine -
Philippe Trolliet -
Ralf Corsepius -
Roman Langolf -
Stefan Heuberger -
Zeimet Alex