RootForum Community

Hallo!

Ich habe einen neuen Server, nun steht ein Umzug aller Daten etc. von meinem alten Server dorthin an. Auf beiden Servern ist Debian 3.1 installiert. Es laufen ein Webserver, Mailserver und ne Datenbank auf dem alten Server.
Am liebsten würde ich einfach ein Fullbackup vom alten Server machen und das auf dem neuen einspielen. Ich bin mir nur nicht sicher welche Ordner/Dateien ich dabei auf dem neuen Server nicht überschreiben darf (Netzwerkkonfiguration/Hardwarespezifisches... etc.). Hat da jemand einen Tip, worauf ich beim kopieren achten muß? Oder gibt es eine bessere Methode für den Umzug?

Schonmal Danke & Gruss,

Marc

Der neue Server ist schon eingerichtet?
Dump von der DB erzeugen, FTP/Web/Mail-Daten einpacken und per SCP auf den neuen Server schieben. Kannst dir noch die Daten aus /etc sichern, um deine Serverdienste wieder gleich einzurichten. Vorsicht: IP-Adressen etc. entsprechend anpassen.
Wenn es hardwaremäßig gleich oder ähnliche Server sind, geht vielleicht auch ein Festplattendump über das Rescue-System, aber ob das so problemlos ist, kann ich dir leider nicht sagen.

ne, der server ist noch nicht eingerichtet, ist nur ein minimalsystem drauf. deswegen würd ich gerne soviel wie möglich per kopieren erledigen.

in welchen ordern/dateien ist denn die netzwerkkonfiguration? da man da ja so nicht dran rumschraubt kenne ich mich da nicht so aus...

hardwaremäßig ist zumindest ein anderer prozessor drin, die anderen komponenten denke ich auch. welche ordner/dateien sind denn dafür zuständig?

marc76 wrote:ne, der server ist noch nicht eingerichtet, ist nur ein minimalsystem drauf. deswegen würd ich gerne soviel wie möglich per kopieren erledigen.

Du kannst den ganzen Server kopieren. Auf beiden Kisten das Rettungssystem booten, Festplatte mounten (alt), bzw. partitionieren, formatieren, mounten (neu), dann im Rettungssystem des Zielsystems Partition für Partition mit "rsync" kopieren, Netzwerkparameter anpassen, Bootloader schreiben, rebooten, fertig.

Möglicherweise musst Du dem Zielsystem einen anderen Kernel und/oder eine andere Ramdisk unterschieben.

da man da ja so nicht dran rumschraubt kenne ich mich da nicht so aus...

Kommt drauf an: Admins machen das den lieben Tag lang. So denn lass entweder die Finger vom Systemteile kopieren oder lern das so weit, daß Du weißt, was Du machst, sonst bekommst Du Probleme. (Kein Flame sonderm ernstgemeinte Schadensbegrenzung!).

Prinzipiell gibt es bei Unix einen Filesystemstandart und eine Trennung von Daten und Programmen. Im Prinzip gilt /var, /home, /usr/local, /usr/lib/cgi-bin /usr/src und evtl /opt kopieren, den Rest kannst Du überbügeln und neumachen. Für /etc gilt daß da deine Konfigurationen liegen Die Du vielleicht erhalten willst(aber nur, wenn Du auch weisst, was Du tust, sonst mach's lieber neu)

Grundsätzlich heißt, daß es horrend ist, wie wenig sich danach gerichtet wird. Also etwas genauer:

/etc fliegen Konfigurationen rum. Die mußt Du aufheben bis der andere Rechner läuft. Glaub mir irgendeine Konfiguration vergisst Du immer und dann bist Du am suchen, wie das war - aufheben zum nachschauen.

/usr/local sind(bzw sollten) auschließlich von Dir per Hand installierte Programme sein(und die sollten auch nur dort oder in /opt liegen): mußt Du kopieren, sonst sind die weg. Allerdings gibt es ein paar Dists die es nicht lassen können da auch was hinzuinstallieren(fprot war da manchmal... )

/opt ist wie /usr/local nur weniger streng. [Ähhhm manche Dists können es nicht lassen ... ].

/var: Hier liegen Daten von Datenbanken, Webserver und FTPserver, Mailverzeichnisse ... oft Systemvariablen, manchmal ganze Programme nochmal verlinkt(z.b. QMail!). Chroots sind auch oft hier. Das Gute: es sind Verzeichnisse.
/usr/lib/cgi-bin : gehört nicht nach /usr/lib aber da sind deine cgi`s -> kopieren.
/usr/lib und /usr/share sind wie alles unter /usr System resourcen - aber insbesonderes java versteckt da oft Sachen, die eigentlich nach /usr/local oder /var gehörten. Java selber befindet sich oft in /usr/lib/j* auch wenn es per Hand installiert wurde(horror!) dazu sind da oft Bilder u.ä.
/home: das ist klar oder? Kopieren(und Rechte nachher reparieren)!
/htdocs : SuSE special Kopieren!

Dann haben wirs, das größte Problem ist /etc und /var. Da rate ich erst neumachen und dann, wo Dir auffällt, daß Du es brauchst kopieren.
Der Vollständigkeit halber: es gibt Dists(früher auch deutsche Marktführer), die Konfigurationen oder rcscripte in /sbin haben(no comment). Dazu gibt es auch manchmal selbsterzeugte Gerätedateien in /dev (aber bei einem Umzug eher irrelevant).

lucki2 wrote:es gibt Dists(früher auch deutsche Marktführer), die Konfigurationen oder rcscripte in /sbin haben(no comment).

Ähm, nur aus Neugierde: Welche SuSE war das? SuSE >=7.0 war es nicht...

Nachtrag: BTW, SuSE ist seit Urzeiten vollständig zur LSB und somit auch zur FSH konform. Daher ist Dein /htdocs flachs...

Das hat SuSE seit je her behaupted. Richtig ist auch, daß sich einiges (imho zum besseren) geändert hat, womit die sich Frage stellen ließe, ob das nun vorher oder nacher kompatibel war. Unterverzeichnisse in / sind nach FHS "verboten". Aber da sind wir bei Religion.
SuSE hatte früher rcscripts in /sbin. Hat das jedoch geändert. Das ging nicht ganz reibungslos ... Sind rar geworden die Dists mit rc in /sbin. Ich hatte auch geschrieben "der Vollständigkeit halber"
Ich kann Dir auch verraten, daß ich seit gut einem Jahr keine einzige SuSE mehr zu administrieren habe aber auch daß ich SuSE nie für allgemein schlecht hielt.

Mir geht es um praktik. Also, was muß $admin kopieren. Da gibt es ein paar Unterschiede. Vielleicht fällt Dir ja noch mehr ein, was wichtig ist um $admin einen Start zu geben. Eigentlich ist es das, was nicht über Softwaredistribution verteilt wird. Das zu trennen war auch ein Ziel von FHS und findet in /opt und vor allem /usr/local seinen Niederschlag mit der Forderung, daß dies über Distribution nicht überschrieben werden soll. Das beantwortete aber die Frage unseres $admin: alles, was die neue Softwaredistribution überschreiben darf(bzw davon überschrieben wird), muß er nicht kopieren! Ja, puristik vrs. praxis.

Und ... Du hast recht: Nach FHS sind Services unter /srv. Calm: das ist neu, gabs davor nicht und wie viele Server kennst Du, die www,ftp ... unter /srv haben? Bevor es /srv gab, hat imho das am ehesten nach /var gepasst. ich finde dieses /srv übrigens sehr gut! Erleichtert nämlich künftig unserem $admin die Entscheidung, was zu kopieren ist! Ein Fehler ist imho Mailspool(bei ISP - sonst auch $HOME) dann nicht auch nach /srv zu tun - mit dem gleichen Grund: Migration und Highavailability.

lucki2 wrote:SuSE hatte früher rcscripts in /sbin. Hat das jedoch geändert. Das ging nicht ganz reibungslos ... Sind rar geworden die Dists mit rc in /sbin. Ich hatte auch geschrieben "der Vollständigkeit halber"

Das ist das einzige, was ich an SuSE vermisse. Ich lege mir unter debian die Symlinks von /etc/init.d/$DIENSTNAME nach /sbin/rc$DIENSTNAME teilweise wieder händisch an (ok, könnte auch nach /usr/local/sbin gehen).
Es ist für einen faulen Kerl wie mich schon ein Unterschied, ob ich /etc/init.d/apache2 reload oder rcapache2 reload eintippe.

Einfacher wär's wohl per Shell-Alias. ;)

Da könnten wir länger Diskutieren, ist nur ein bischen OT.

Es ist imho für $admin nur wichtig, zu wissen, daß es in seltenen Fällen sein kann, daß in /sbin Scripte liegen, die Konfiguration enthalten und er schauen muß, wenn sich Programme darauf verlassen, daß die sie auch finden - sonst wundert er sich.

@Thorsten: :idea: alternative: NB: Das SuSE Problem waren nicht direkt die rcscripts in /sbin, sondern ein klamüsel von Scripts, die von rcconfig aufgerufen wurden, aus denen die rcscripts erstellt wurden. Die rcconfig wurde wiederum über Yast verwalted und in jedem Script stand drin, daß es nicht verändert werden darf. Das ganze war ziemlich abhängig voneinander und damit ein bischen ein Stolperstein für Leute, die per Hand anpassen wollten/mußten. Problem war auch, daß nach verändern von solchen Scripts irgendwer wieder Yast verwendete, das dann nicht unbedingt nur die Änderungen rückgängig machte, sondern seine Änderungen irgendwo in die Scripts reinschrieb, weil es die Struktur der Datein nicht mehr kannte. Das Ergebnis war dann Buchstabenmüll, der schwer wieder in Griff zu kriegen war, geschweigeden damit den Rechner Booten zu wollen. Naja und das ist natürlich auch nicht immer sofort aufgefallen(weil unzählige Scripts), sondern erst, wenn der Rechner nicht mehr Booten wollte....

danke für die tips, umzug ist geglückt :-D
habe basierend auf der minimalinstallation alles neu installiert, und dann nur die benötigten configs/daten rüberkopiert.