Archiv verlassen und diese Seite im Standarddesign anzeigen : Wie backupe ich am besten?
und zwar würde ich gerne folgende platte backupen:
/dev/hda1 * 1 13 104391 83 Linux
/dev/hda2 14 4865 38973690 8e Linux LVM
ist ein fedora core 3 system.
bis jetzt übertrage ich komplett /dev/hda unter knoppix auf meine firewireplatte. aus bequemlichkeitsgründen würde ich das aber gerne im laufenden Betrieb tun.
hat mir dazu jemand einen vorschlag?
außerdem wüsste ich gerne, wie ich unter knoppix diese dumme LVM partition mounten kann??
vielen dank im voraus
euer morten
aso, hier noch:
/dev/mapper/VolGroup00-LogVol00 on / type ext3 (rw)
none on /proc type proc (rw)
none on /sys type sysfs (rw)
none on /dev/pts type devpts (rw,gid=5,mode=620)
usbfs on /proc/bus/usb type usbfs (rw)
/dev/hda1 on /boot type ext3 (rw)
none on /dev/shm type tmpfs (rw)
/dev/hdb1 on /hdb type ext3 (rw)
none on /proc/sys/fs/binfmt_misc type binfmt_misc (rw)
sunrpc on /var/lib/nfs/rpc_pipefs type rpc_pipefs (rw)
/dev/sda1 on /test type ext2 (rw)
Mein Tipp -> rsync ... such mal hier im Board oder geh goooglen.
hmm wie wäre es mit:
lvcreate -L500M -s -n backup /dev/mapper/VolGroup00-LogVol00
könnte es damit funktionieren?
wie schon gesagt, ich möchte im laufenden Betrieb ein möglichst konsistentes backup machen
wie sieht es mit dd if=/dev/hda of=/test/281005.bin während des betriebs aus? kann ich mir eigentlich sparen, oder wäre dieses image zurückgespielt wenigstens halbwegs verwendbar?
rsync bringt mir eigentlich nix, ich möchte immer die komplette platte/partition backupen
Versteh ich nicht?
Du kannst doch rsync sogar als Daemon laufen lassen ... und der kontrolliert und backuped die ganze Platte/Partition.
Mit rsync kommts Du nur nicht an den MBR ran, ansonsten kannst Du alles damit sichern. :o
Ja, mit rsync mache ich das auch immer:
rsync -a --delete /quelle /ziel
"--delete" bedeutet, dass in /quelle nicht mehr vorhandene Dateien von /ziel gelöscht werden. Evtl. willst du auch noch ein paar Sachen (z.B. den Mülleimer) ausschließen, dann kannst du das via "--exclude=" machen.
Allerdings ist das kein Raid-System, das ständig alles neue auf deine Firewire-Platte schreibt. Ich mach das halt in regelmäßigen Abständen und schalte meine externe Platte nur dazu an (brauch sie ansonsten nicht).
danke für die antworten!
wie ist das bei rsync mit den gerade noch geöffneten dateien oder /dev
würde ein
rsync -a --delete / /firewireplatte
funktionieren?
wie steht es mit dem zurückspielen bei laufendem system?
grüße
morten
Nö, würde nicht funktionieren, da das Ziel fehlt *g Aber ich denke du meinst es beispielsweise so (Achtung: Mountpunkt angeben und nicht das Gerät!):
rsync -a --delete /home /media/sda1
Zum laufenden System: Das sollte gar nichts machen, allerdings kannst du dir ausmalen, dass noch nicht gespeicherte Änderungen dann auch nicht auf der Reserve-Platte sind. Ich logge mich deswegen immer aus (KDE) und gib's dann in der Konsole ein. Das Backuppen dauert ja in der Regel net soo lange, in der Zeit kann man ja auch zur Abwechslung mal was machen, wozu man keinen PC braucht :p
in der Zeit kann man ja auch zur Abwechslung mal was machen, wozu man keinen PC braucht :p
hmm... mir fällt da nix ein! :confused:
eigentlich meinte ich dass ich komplett / backuppen möchte. natürlich muss ich da meine gemountete platte ausschliessen. wie schauts mit /dev aus? sollte ich auch draußen lassen? noch was anderes, das ich beachten muss, wenn ich so vorgehe?
das nächste problem: ich bekomme unter knoppix diese partition nicht gemountet... extrem ungeschickt für ein restore wenn das system nicht mehr von selbst läuft. und ich hab eigentlich gar kein raid!
Zum laufenden System: Das sollte gar nichts machen, allerdings kannst du dir ausmalen, dass noch nicht gespeicherte Änderungen dann auch nicht auf der Reserve-Platte sind. Ich logge mich deswegen immer aus (KDE) und gib's dann in der Konsole ein. Das Backuppen dauert ja in der Regel net soo lange, in der Zeit kann man ja auch zur Abwechslung mal was machen, wozu man keinen PC braucht :p
Noch besser, ich mach das per script-Aufruf nachts über einen Cronjob-Eintrag, da lässt es sich gut schlafen dabei :p
eigentlich meinte ich dass ich komplett / backuppen möchte. natürlich muss ich da meine gemountete platte ausschliessen. wie schauts mit /dev aus? sollte ich auch draußen lassen? noch was anderes, das ich beachten muss, wenn ich so vorgehe?
das nächste problem: ich bekomme unter knoppix diese partition nicht gemountet... extrem ungeschickt für ein restore wenn das system nicht mehr von selbst läuft. und ich hab eigentlich gar kein raid!
/dev kannst du ja beim ersten mal mit backuppen, soweit ich weiß ändert sich da eh nix (sind außerdem nur ein paar kb). Sonst fällt mir nix weiteres ein, aber ich hab mit einem kompletten Sys-Backup keine Erfahrung, ich sicher nur meine Daten.
Zu deinem Problem unter Knoppix kann ich nix sagen, trotz der vielen Infos, die du mitgeschickt hast ;-) Meinst du die Partition auf der Firewireplatte?
drunkenPenguin
03.11.05, 06:39
/proc, /sys, /dev, /tmp und /var/tmp sichert man in der Regel nicht mit, da der Inhalt dieser Verzeichnisse sich bei einem Neustart sowieso ändert bzw. neu geschrieben oder gelöscht wird.
Den MBR sichere ich eigentlich auch nie mit. Wenn da was kaputt geht, repariere ich es mit Knoppix. Geht in Verbindung mit grub auch sehr gut.
Ein "komplettes" Backup mit dd halte ich für unsinnig, weil die neue Partition exakt die gleiche Größe wie das Backup-Image haben muss. Das Rumfrickeln danach lohnt nicht wirklich.
Zu deinem Problem unter Knoppix kann ich nix sagen, trotz der vielen Infos, die du mitgeschickt hast ;-) Meinst du die Partition auf der Firewireplatte?
okay, danke schön, so komm ich auf den richtigen erleuchteten weg!
ich meine natürlich
/dev/mapper/VolGroup00-LogVol00 on / type ext3 (rw)
firewire platte ist kein problem! evtl. sollte ich mal n extra thread machen...
/proc, /sys, /dev, /tmp und /var/tmp sichert man in der Regel nicht mit, da der Inhalt dieser Verzeichnisse sich bei einem Neustart sowieso ändert bzw. neu geschrieben oder gelöscht wird.
Dass proc,sys etc. sich ändern wusste ich, aber dev? Wie kann man sich denn diese Dateien erklären, sind das nur so ne Art Links? Nur aus Interesse...
drunkenPenguin
04.11.05, 01:27
Dass proc,sys etc. sich ändern wusste ich, aber dev? Wie kann man sich denn diese Dateien erklären, sind das nur so ne Art Links? Nur aus Interesse...
Da habe ich mich etwas unklar ausgedrueckt, sry. Vielleicht habe ich es ja auch nicht richtig verstanden. Man moege mich korrigieren.
Die Dateien unter /dev existieren natuerlich durchaus, nur muss bspw. /dev/hdb hardwareseitig nicht vorhanden sein.
Es ist auch nicht richtig, davon zu sprechen, dass alles unter /dev dynamisch beim Booten angelegt wird. Die Dateien sind natuerlich immer da, nur sind die Geraete/Partitionen/Schnittstellen etc., die ueber diese Dateien angesprochen werden, selbstverstaendlich nicht immer real vorhanden. Beim Booten bzw. beim Hinzufuegen von Hardware etc. spricht der Kernel ueber einen Treiber die Geraete an. Was unter /dev liegt, interessiert ihn erst mal nicht. Erst wenn es darum geht, dass z. B. mehrere Programme auf ein Geraet zugreifen, bietet es sich an, dieses unter /dev quasi zu abstrahieren.
Zudem muss ich natuerlich meinen vorigen Beitrag etwas revidieren: wenn man Symlinks unter /dev angelegt hat, sollte man dieses Verzeichnis natuerlich schon sichern.
Ich hoffe, ich habe das jetzt halbwegs richtig erklaert.
Sollte sicherlich keine Kritik sein, hat mich eben nur interessiert, was das unter /dev überhaupt ist. thx!
Dass proc,sys etc. sich ändern wusste ich, aber dev? Wie kann man sich denn diese Dateien erklären, sind das nur so ne Art Links? Nur aus Interesse...
Das kommt darauf, bei udev werden die tatsaechlich wie bei proc "live" angelegt, kommt kein udev zur Anwendung (z.B. kernel <2.6) sind die Dateien alle da.
Hi!
Das kommt darauf, bei udev werden die tatsaechlich wie bei proc "live" angelegt, kommt kein udev zur Anwendung (z.B. kernel <2.6) sind die Dateien alle da.
Aber auch nur dann, wenn man kein devfs verwendet.
Gruß
fuffy
Powered by vBulletin® Version 4.2.5 Copyright ©2024 Adduco Digital e.K. und vBulletin Solutions, Inc. Alle Rechte vorbehalten.