Komplettbackup bei Anbieterwechsel transferieren?

[systemkiller]

ich habe vor den anbieter zu wechseln. wie kann ich mein komplettes betriebssystem incl. daten zum neuen anbieter übertragen? von den einstellungen mal abgesehen. der neue anbieter hat suse 8.1 draufgespielt, ich habe debian 3 auf dem alten system am laufen. gibt es eine möglichkeit, den kompletten festplatteninhalt zu spiegeln? das system sollte danach wieder lauffähig sein. beide anbieter verwenden dieselbe hardware. recovery wird vom neuen anbieter unterstützt. leute, versteht mich nicht falsch. ich muss ja keine experimente machen, wenn irgendjemand die lösung schon kennt :) daher meine nachfrage.

[dea]

na wenn Du jetzt jetzt schon Debian am laufen hast geht es doch ganz einfach:

Auf dem Alten System 'dpkg --get-selections > Paketliste.txt' und schon hast Du die Installierte Software protokolliert. Die kannst Du auf dem neuen System, nach der Umstellung auf Debian, wieder mit einem beherzten 'dpkg --set-selections < Paketliste.txt' zurückspielen.

Für die Daten, Konfigurationsdateien, usw. gibt's ohne Ende Programme. Du kannst mit tar, cpio, usw. anfangen und bei großen Backuplösungen aufhören. Tar dürfte wohl am einfachsten sein.

[königrollo]

interessant. gibt's eingentlich bei suse was ähnliches wie diesen "dpkg --get-selections"-befehl, um sich die installierte software ausgeben zu lassen?
besonders interessant fänd ich übrigens einen ähnlichen befehl für die installierten perl-module.

rollo

[Matthias Diehl]

Probier mal

Code: Select all

rpm -qa | grep perl

[dopefish]

wenn du mutig bist kannst du einfach beide systeme in den rescue modus fahren und dann vom neuen server ein

Code: Select all

ssh user@bisheriger-server.de "dd if=/dev/hda | gzip -fc" | gunzip -fc | dd of=/dev/hda

machen, je nachdem wieviele Daten du transferieren muss hast du (ein paar minuten/stunden ... ) dannach eine 1:1 Kopie der Platte auf dein neues System. (nicht vergessen sachen wie netzwerkeinstellungen und bootmanager anzupassen vor dem reboot)

[dea]

Und genau das ist nicht nur mutig sondern sträflich leichtsinnig. Unfug.

Abgesehen davon, dass dd nicht zwangsläufig alles liest (machma google auf dd_rescue) kopierst Du Dir damit auch die Partitionstabelle - wenn die "neue" Platte kleiner als die "alte" ist gehen Daten verloren, andersherum hast Du das zweifelhafte Vergnügen, Dich mit der Repartitionierung der Festplatte im laufenden Betrieb auseinandersetzen zu dürfen.

Finger weg von solchen "Lösungen".

[oxygen]

Also ich würde nur die Nutzdaten und geänderte Konfigurationen von wichtigen Programmen übernehmen. Alles andere wäre mir zu heiß. Wenn man auf beiden Rechnern die gleiche Distribution läuft, kann man die Paket auswahl übernehmen, spart arbeit. Das wars aber auch...

[dea]

Dem sowieso ;)

Eine anständige Suche über die Listenarchive der $DISTRIBUTION zeigt dann auch schnell die wesentlichen Verzeichnisse, sowie eventuelle spezifische Fallstricke auf.

[dopefish]

dass die gleiche platten vonnöten sind ist ja selbsredend, er schreibt ja auch dass er die gleiche hardware hat. Ich hatte bisher nie Probleme mit die Lösung, anstatt dd kann man aber genausogut einfach die partitionen mounten, ein tarball vom system machen und diesen übertragen, das wäre die konventionellere Lösung. Oder man nimmt Rsync zur hilfe um Ã?nderungen abzugleichen nach der Basisinstalltion, u.s.w. ....
Sofern man immer nur die distributionseigene Paketverwaltung benutzt um software zu installieren ist es natürlich ein klacks einfach die Pakete auf den neuen Server zu installieren und die Nutzdaten und Konfiguration dannach rüberzuziehen, aber wenn man vieles vom Source kompiliert hat und nicht alles davon unter /usr/local liegt ist es mühselig alles erneut aufzuziehen.

[roi]

auf die gefahr hin, dass ich jetzt gekillt werde :-)

ich habe den umzug von 1und1 zu strato mit einem tar-komplettbackup, verteilt auf mehrere tar-files, erledigt (ausnahme logfiles und andere files dieser art, die nicht auf dem neuen system benoetigt werden). kernel neu kompiliert, fstab und so weiter angepasst, ip-settings, namensaenderung und so weiter und so fort. nun laeuft ein klon des alten systems auf der neuen hardware. einziger unterschied ist der kernel, ip-adresse und der hostname.

[dea]

Wieso gekillt? Die Verwendung von tar oder cpio stellt in meinen Augen immer noch die sauberste Varaibte dar. Würde ich umziehen, ichj würd's nicht ander machen.

K - vielleicht die Datenbanken dumpen/exportieren und nicht die DB-Files kopieren; Zertifikate, GPG- und SSH-Keys würde ich sicherlich auch nicht mitnehmen sondern auf dem neuen Host neu erzeugen. Aber so etwas wären Ausnahmen.

[roi]

Wieso gekillt?

meinte ich deswegen, weil sich meine vorredner da teilweise eins abgefummelt haben... :-)

K - vielleicht die Datenbanken dumpen/exportieren und nicht die DB-Files kopieren; Zertifikate, GPG- und SSH-Keys würde ich sicherlich auch nicht mitnehmen sondern auf dem neuen Host neu erzeugen. Aber so etwas wären Ausnahmen.

klaro, solche feinheiten habe ich oben weggelassen. wobei eine kopie der mysql-files bei runtergefahrenem mysql-server ja kein problem darstellen, oder?

ok, den ssh-key und eventuelle zertifikate koennte man neu erzeugen, richtig. hab ich nicht gemacht, der alte server stirbt eh, dann ist der key / das zertifikat auch wieder einmalig.

[dea]

K - vielleicht die Datenbanken dumpen/exportieren und nicht die DB-Files kopieren; Zertifikate, GPG- und SSH-Keys würde ich sicherlich auch nicht mitnehmen sondern auf dem neuen Host neu erzeugen. Aber so etwas wären Ausnahmen.

klaro, solche feinheiten habe ich oben weggelassen. wobei eine kopie der mysql-files bei runtergefahrenem mysql-server ja kein problem darstellen, oder?

Wenn Du/man eh' eine gewisse Zeit offline einplant bzw. vertragen kann ist das sicherlich OK. Genauso wie ein regelmäßiger Offline-Backup der DB.

Ein Dump hingegen lässt sich auch online veranstalten, so dass beispielsweise Foren nicht zwangsläufig offline sind, sondern ggf. lediglich read-only geschaltet werden bräuchten ;)

ok, den ssh-key und eventuelle zertifikate koennte man neu erzeugen, richtig. hab ich nicht gemacht, der alte server stirbt eh, dann ist der key / das zertifikat auch wieder einmalig.

Was mit dem SSH-Key funktionieren mag ist für SSL-Zertiikate unsinnig. Da kann es schnell zu Fehlern kommen, die dem weniger versierten Nutzer (jaja, wer ist das schon *s*) nicht erklärbar sind. Ã?hnliches gilt für Benutzerzertifikate. (Auch siicherlich sehr lustig sind IPSec-Zertifikate bzw. -Konfigurationen wenn sie unverändert übernommen werden)

Je nach Komplexität und Menge der Zertifikate würde ich eine Neugenerierung bzw. erneute Signierung empfehlen.