Debian-Serverinhalt umziehen - wie?

[Trow]

Hi.

Weiß jemand wie ich alles in / (also im oberstern Verzeichnis) auf einen anderen Server ziehen kann? Quellserver läuft mit Debian Lenny und der Zielserver mit CentOS 6.5 (beide 64-bit).

Mit wget oder curl konnte ich keinen Befehl finden der funktioniert, also SFTP / SSH kann wohl vergessen. Dann dachte ich mir ich versuche es mit vsftpd - aber das Teil macht seinem Namen ("Very Secure File Transfer Protocol Daemon") wirklich alle Ehre, wichtige Verzeichnisse wie /var sind geschützt und ein Zugriff - egal welche Chroot-Einstellung man trifft - ist unmöglich.

Als tar packen geht leider nicht, da die Platten des Quellservers total voll sind. Sonst würde ich einfach alles in / "verpacken", rüberziehen und dann wieder entpacken.

Weiß jetzt nicht mehr was ich noch versuchen soll, hat jemand eine Idee?

 

[LieberNetterFlo]

und du bist sicher dass das überhaupt geht? Das eine is Debian und das andere RHEL ... ich glaube das klappt nicht.

 

[Suxxess]

Vielleicht geht es mit WinSCP:
http://winscp.net/eng/download.php

Aber ich würde dir empfehlen das Notfallsystem von deinem Anbieter zu starten damit die Dateien nicht im Gebrauch sind dann sollte es eigentlich klappen.
Aber du willst doch keine 1 zu 1 Kopie produzieren die danach sogar noch lauffähig wäre...oder?

 

[SkaFan]

Ist hoffentlich kein Root-Server, oder?
Wer mit so wenig Ahnung einen Root-Server betreibt...
Du hast dich offensichtlich noch niemals mit der Rechteverwaltung oder den Grundlagen von Linux beschäftigt.

"Mit wget oder curl konnte ich keinen Befehl finden der funktioniert, also SFTP / SSH kann wohl vergessen."
wget und curl haben mal gar nix mit SSH/SFTP zu tun!

"Dann dachte ich mir ich versuche es mit vsftpd"
Dazu müstest du / als / im FTP setzen, wer das macht gehört gesteinigt!

"Als tar packen geht leider nicht, da die Platten des Quellservers total voll sind."
Das wäre ein weg, mit tar packen incl. der Rechte, Ziel System formatieren, tar entpacken und mit grub das System wieder bootfähig machen.

Per NFS und Export kann man auch alles kopieren, dazu beide System z.B. per SystemRescueCD booten und übers Netzwerk (Internet geht auch) kopieren...

Das geht aber nur wenn der Kernel mitspielt, das "neue" System wäre dann aber auch wieder Debian und nicht CentOS.

Das kann man nicht so einfach kopieren!

 

[Trow]

Vielleicht geht es mit WinSCP:
http://winscp.net/eng/download.php

Guter Tipp - das geht natürlich, aber ich habe zu Hause nur eine 100 Mbit Leitung und der Server hat 8 TB an Daten.

Aber ich würde dir empfehlen das Notfallsystem von deinem Anbieter zu starten damit die Dateien nicht im Gebrauch sind dann sollte es eigentlich klappen.

Leider gib's kein Rescue-System bei diesem Server. Sonst würde ich dieses starten, die Platten mounten usw.

Aber du willst doch keine 1 zu 1 Kopie produzieren die danach sogar noch lauffähig wäre...oder?

Nein will ich nicht, dass ist der Server eines Freundes und der weiß nicht mehr wo er was gespeichert hat - deswegen soll ich nach Möglichkeit alles sichern. Sonst würde ich nur Logs und die Webs sichern. Ist aber wirklich sehr undurchsichtig was sich wo befindet.

Du hast dich offensichtlich noch niemals mit der Rechteverwaltung oder den Grundlagen von Linux beschäftigt.

Nein, warum auch? Ich verwende Microsoft Windows Server. Mit ASP.Net bin ich auch viel besser vertraut als mit PHP. Ich mach hier nur eine Gefälligkeit.

wget und curl haben mal gar nix mit SSH/SFTP zu tun!

Ich dachte auch wget wäre nur ein er simpler "Downloader", der mit FTP und HTTP gut funktioniert. Aber es gibt Unmengen an Tutorials (oder ich nenne es besser "Ideen") die etwas anderes sagen. Hätte meine FTP-Idee funktioniert, hätte ich mir mit wget -m ftp://username:password@www.mydomain.tld/ alles runterladen können.

Dazu müstest du / als / im FTP setzen, wer das macht gehört gesteinigt!

Die Idee ist super, auf einem Produktivsystem aber ziemlich gefährlich. Ich will ja nur irgendwie den Inhalt haben...

"Als tar packen geht leider nicht, da die Platten des Quellservers total voll sind."
Das wäre ein weg, mit tar packen incl. der Rechte, Ziel System formatieren, tar entpacken und mit grub das System wieder bootfähig machen.

Das soll einfach nur gesichert werden, um es nacher auswerten zu können. Das soll nie wieder laufen und ist jetzt auch kein Produktivsystem was aus dem Internet 24/7 öffentlich erreichbar ist. Rechte müssen nicht erhalten bleiben.

Leider kriege ich PureFTPd nicht zum laufen und weiß nicht warum. Hat noch jemand eine Idee?

 

[Hoeze]

Was wäre, wenn du eine 1:1 Kopie der Festplatte erstellen würdest? Der Anbieter wird dir doch ne Rettungsdisc einlegen können..?
Ansonsten (wenns dir nur um die reinen Daten geht) könntest du auch einfach vom Zielserver aus per SCP versuchen, das '/' des Quellservers auf den Zielserver rüberzukopieren.
Was genau ist dein Ziel?

Ergänzung (11. März 2014)

Bsp.:
ssh root@zielserver.de
scp root@quellserver.de:/ /tmp/quelle/

 

[Trow]

Was wäre, wenn du eine 1:1 Kopie der Festplatte erstellen würdest? Der Anbieter wird dir doch ne Rettungsdisc einlegen können..?

Gibt's leider nicht beim Anbieter. Das ist ein "Null Service Provider".

Ansonsten (wenns dir nur um die reinen Daten geht) könntest du auch einfach vom Zielserver aus per SCP versuchen, das '/' des Quellservers auf den Zielserver rüberzukopieren.

Danke, die Idee ist super! Wie stelle ich das konkret korrekt an? Alle meine Versuche schlagen fehl, bin wie gesagt keiner der besonders gut mit Linux auskennt und ich google schon seit 25 Minuten...

Was genau ist dein Ziel?

Einfach die Daten kriegen, da der Server in wenigen Tagen abschaltet wird. Die Person die das macht wertet die Daten dann anscheinend auf seinem anderen Server aus.

 

[mensch183]

Via NFS mounten. Via "cp -a" alles außer Spezialkram ala /dev, /sys, /proc kopieren.

 

[Hoeze]

Danke, die Idee ist super! Wie stelle ich das konkret korrekt an? Alle meine Versuche schlagen fehl, bin wie gesagt keiner der besonders gut mit Linux auskennt und ich google schon seit 25 Minuten...

So, denke ich:

Bsp.:
ssh root@zielserver.de
scp -r root@quellserver.de:/ /tmp/quelle/

Das -r steht für rekursiv, hab ich vergessen.
Kanns leider nicht testen, müsste aber funktionieren

 

[Trow]

* edit *

---------

LOL, wollte gerade schreiben dass das erste leider nicht ging. Aber du warst schneller

So, denke ich:

Das -r steht für rekursiv, hab ich vergessen.
Kanns leider nicht testen, müsste aber funktionieren

Danke, gleich mal testen!

Ergänzung (11. März 2014)

Tausend Dank, der Download startet jetzt tatsächlich! Kann ich das nach Abschluss auf Vollständigkeit prüfen?

[B]
[FONT=comic sans ms][SIZE=4]3837:~# scp -r root@67.227.166.155:/ /server_backup_3837[/SIZE][/FONT][/B]

Habe das gerade mit STRG + C abgebrochen, da ich das nacher starten möchte. Jetzt wollte ich die bereits geladenen Dateien wieder löschen aber der Ordner /server_backup_3837 ist leer? Lädt der das vielleicht woanders hin oder stimmt da was nicht?

 

[Hoeze]

Wenn du ein -v dranhängst bekommst du mehr Infos.

Grundsätzlich lädt der das schon in den Ordner /server_backup_3827/, das sollte so schon funktionieren.
Versuchs mal mit rsync, das ist vielleicht etwas komfortabler:

rsync -r -v root@67.227.166.155:/ /server_backup_3837/

Eine Frage:
Du bist auf einer Maschine namens 3827.
Hat diese Maschine etwa die IP 67.227.166.155?
Du musst den Befehl auf dem ZIELrechner ausführen, nicht auf dem QUELLserver

 

[Trow]

Bin jetzt schon etwas weiter. Wenn ich exakt das scp -r root@67.227.166.155:/ /server_backup_3837 auf dem Quellserver ausführe (vorher in den Zielserver eingeloggt und dann ssh root@67.227.166.155 -p 4519 eingegeben), wird der Ordner server_backup_3837 auf dem Quellserver, nicht auf dem Zielserver erstellt.

Wenn ich das scp -r root@67.227.166.155:/server_backup_3837 / auf dem Quellserver ausführe (vorher in den Zielserver eingeloggt und dann ssh root@67.227.166.155 -p 4519 eingegeben) passiert quasi nichts:

3827:~# scp -r root@212.133.106.33:/server_backup_3837 /
root@212.133.106.33's password:
3827:~# scp -r root@212.133.106.33:/server_backup_3837 /
root@212.133.106.33's password:
3827:~#

Ich führe alle Befehle auf dem Zielserver aus. Bin ja dann aber über SSH quasi in dem Quellserver.

Quellserver-IP: 67.227.166.155 | Hostname: 3827
Zielserver-IP: 212.133.106.33 | Hostname: srv67

Das mit rsync versuche ich gleich mal.

 

[Suxxess]

Wenn du nur wissen willst was wo ist:

http://www.tippscout.de/linux-grosze-dateien-finden_tipp_1653.html

ls -lahS $(find / -type f -size +10000k)

Die Ausgabe dann in eine Datei umleiten:
ls -lahS $(find / -type f -size +10000k) >> /home/user/index.txt

Und fertig damit hast du einen groben Überblick und musst keine 8 TB kopieren...

 

[Trow]

Ok danke für den Tipp, hab's mir mal angeschaut - aber ich soll's trotzdem kopieren... Da Server A und B aber jeweils mit 2 Gbit/s angeschlossen sind, dauert das ja aber so oder so keine 9 Stunden, sofern dann auch die I/O-Raten stimmen.

 

[westef]

Du hast da wohl irgendwas falsch verstanden. Du loggst dich per SSH auf dem Zielserver ein. Dann führst du auf dem Zielserver den Befehl "scp -r root@67.227.166.155:/ /server_backup_3837" aus.

Das sorgt dafür, dass sich scp zu 67.227.166.155 verbindet und alle Dateien in / in den Ordner /server_backup_3837 auf den Zielserver runterlädt.

edit:// Sind das eigentlich Zufalls-IPs oder hat dein Kumpel wirklich was mit "Drain Cleaning Miami" zu tun? oO

 

[Twostone]

Solltest Du die Möglichkeit haben, eine Live-Linux-Umgebung auf beiden Maschinen laufen lassen zu können, kannst Du auch schlichtweg eine bitweise kopie anfertigen mit:

dd if=/dev/sdX bs=1M | buffer -s 64k -S10m | ssh -p ${PORT} ${USER}@${HOST} 'dd of=/dev/sdX'

Nur kopieren geht auch mit tar:

 tar -crjf - / | ssh -p &{PORT} ${USER}@${HOST} 'tar -xjpf -C / -'

 

[Trow]

Du hast da wohl irgendwas falsch verstanden. Du loggst dich per SSH auf dem Zielserver ein. Dann führst du auf dem Zielserver den Befehl "scp -r root@67.227.166.155:/ /server_backup_3837" aus.

Das Prinzip ist mir schon klar, der Ordner wurde aber wirklich nur beim Quellserver erstellt. Prüfe ich heute Abend noch einmal genau was ich da wo wie eingegeben habe.

edit:// Sind das eigentlich Zufalls-IPs oder hat dein Kumpel wirklich was mit "Drain Cleaning Miami" zu tun? oO

Nur die letzten zwei Ziffern der IPs sind verändert. Keinen Plan was der da so am laufen hat, mir wurde gesagt der würde zur Zeit nix hosten und wäre sonst getrennt vom Internet (was beim Anbieter wirklich geht, noch nie gehört das man einen Server selbständig quasi "nullrouten" kann).

Nur kopieren geht auch mit tar:

 tar -crjf - / | ssh -p &{PORT} ${USER}@${HOST} 'tar -xjpf -C / -'

Danke auch für diesen Tipp, heißt dass das der Quellserver ausgelesen wird und auf dem Zielserver ein tar-Archiv erstellt wird? Sorry für meine Unwissenheit, ich frage lieber nach.

 

[Twostone]

Der erste Teil, also 'tar -crjf -/' sorgt dafür, daß die Daten eingelesen und komprimiert werden, der zweite Teil hinter der Pipe sorgt dafür, daß eine SSH-Verbindung aufgebaut wird, über den die komprimierten Daten geschickt werden. Bevor sie auf die Platte geschrieben werden, werden sie allerdings wieder entpackt. Wolltest Du ein Archiv erstellen?

tar -crjf - / | ssh -p &{PORT} ${USER}@${HOST} 'cat >~/${Archivname}.bz2'

Vorsicht: Es wird alles archiviert, also auch pseudo-Verzeichnisse wie /proc. Daher ist es sinnvoll, sich eine Datei anzulegen, die Verzeichnisse und Dateien in relativen Pfaden aufzeigt, die von der Archivierung ausgeschlossen werden sollten. Dann gibt man für tar auch noch die Option '-X ${Datei}' an.

 

[Trow]

Danke sehr für alle eure Antworten! Hat mir sehr geholfen.

Habe jetzt das ohne Kompression probiert:

scp -r -p -P &{PORT} root@67.227.166.155:/ /server_backup_3837

Das Backup scheint vollständig, -p verwende ich damit die Datumsangaben erhalten bleiben. Ich wollte gerne ein möglichst exaktes Backup machen (1:1 Byte Kopie hat leider im laufenden Betrieb nicht funktioniert und rescue System gibt's wie gesagt nicht) und bin mir nun nicht wirklich über den konsistenten Zustand des Backup sicher.

Glaubt ihr das es jetzt so ok ist? Wäre schlecht wenn irgendwas fehlt oder kaputt ist und ich das erst merke wenn der Server formatiert wurde...