Elegante Möglichkeit für selektiven Restore

Backup, Restore und Transfer von Daten
m.m.
Posts: 45
Joined: 2009-09-07 19:32
 

Elegante Möglichkeit für selektiven Restore

Post by m.m. »

Ich ziehe in Kürze von meinem vServer auf einen Cloudserver. Die Daten (hier /srv/www/vhosts/. komplett) liegen mittels duply und gpg verschuesselte Archive vor. Duply laeuft auch auf dem Zielsystem bereits. Es geht von einem Suse 10.3 mit Plesk 9.2.3 auf ein Suse 11.0 mit Plesk 9.2.3

Problem: Die uid's und gid's auf beiden Systemen sind nicht identisch. Es muessen also entweder alle Files der betroffenen User (und das sind mehr als 2 - leider) entweder auf dem Zielsystem vorher auf die Quelle angepasst werden oder nach dem einspielen von /srv/www/vhosts/ innerhalb bzw. unterhalb dieses Verzeichnisses. Letzteres stelle ich mir im Moment einfacher vor - entsprechende Vorgehensweisen zur Anpassung / Synchronisierung von uid's und gid's gibt es ja zur Genüge.

Ich will aber das Rad nicht neu erfinden: Gibt es für soetwas ein 'Best practice'?
m.m.
Posts: 45
Joined: 2009-09-07 19:32
 

Re: Elegante Möglichkeit für selektiven Restore

Post by m.m. »

Ich will nur die Webpräsenzen unter /srv/www/vhosts/ übertragen, MySQL dumps einlesen und evtl. die Plesk-Config. Der neue Server läuft schon unter 11.0 und ich bin dabei die einzelnen Komponenten anzupassen (memcached, Apache, PHP etc.).

chown -R ist mir bekannt :-)

Aber es gibt mindestens 3 User in 2 Gruppen für x Präsenzen unter srv/www/vhosts/ und nicht alle Dateien haben den gleichen owner bzw group.

Daher dachte ich mir, ich frag halt mal. Ich werde das wohl über sowas wie in http://it.toolbox.com/blogs/locutus/how ... -gid-26368 lösen.
m.m.
Posts: 45
Joined: 2009-09-07 19:32
 

Re: Elegante Möglichkeit für selektiven Restore

Post by m.m. »

Ich hab mir sowas bei Plesk schon gedacht.

Aufgrund schlechter Erfahrungen mit dem Plesk Backup (der mir eineinhalb Mal die Platte vollgeschrieben hat) hab ich das in die Tonne getreten.

Ich wollte eine Migration des Datenbestandes machen (Kunden, Domains etc. _ohne_ wie Inhalte unter /srv/www/vhosts) und den Rest dann von Hand mittels duply und meinem externen FTP Repository.

Ich werde mir ansehen, was die Migration in Bezug auf uid's und gid's der Plesk user (psaadm, psaserv, psacln etc...) macht und dann entsprechend weitersehen.

Ich werde hier darüber schreiben wie es gelaufen ist.
Last edited by m.m. on 2010-03-02 16:28, edited 1 time in total.
m.m.
Posts: 45
Joined: 2009-09-07 19:32
 

Re: Elegante Möglichkeit für selektiven Restore

Post by m.m. »

Kleiner Zwischenstand: Ich hab mir mittlerweile Webmin und Virtualmin installiert und denke, daß ich Plesk in die Tonne treten werden. Wenn möglich, administriere ich den Server sowieso von der Konsole und brauche dafür diesen Überwust an Klicki-Bunti nicht. Und das, was ich remote machen muss wenn ich keinen ssh Zugriff hab, kann ich locker mit Webmin erledigen.
m.m.
Posts: 45
Joined: 2009-09-07 19:32
 

Re: Elegante Möglichkeit für selektiven Restore

Post by m.m. »

Ich habe ja angedroht, daß ich mich mit Feedback melden würde :lol: :

1. Neuer Server läuft unter opsenSUSE 11.0 und Plesk 9.2.3 (<sigh>)

2. Die jeweiligen httpdocs unter /srv/www/vhosts/ konnte ich mittels duply problemlos auf den neuen Server transferieren (Stichwort fetch). Dabei fand ich besonders interessant, daß die Datei Permissions gemäß den Eintragungen in der /etc/passwd / /etc/group des Zielsystems angepasst wurden. Soll heissen, ich habe mir vorher unnötigerweise Gedanken darüber gemacht, wie ich die File-Permissions auf dem neuen System anpasse. Ich habe mir die Perl Scripts nicht angeschaut aber Permissions die vorher 1003/1005 waren sind nun 2523/2524 (das ist jeweils der/die gleiche User bzw. Group). Und das erspart natürlich eine Menge Arbeit. Also, Duply => \:D/

3. Was ist bloss mit Plesk los....auf meinem vServer hat suexec2 mit /usr/bin/php-cgi5 kein Problem (Suse 10.3 mit Plesk 9.2.3). Auf dem neuen System habe ich ein Update von Apache auf 2.2.14 gemacht (letzte Stable Version für 11.0 lt. meinem Repository), dann habe ich entsprechend der KB von Parallels (http://kb.parallels.com/de/430 bzw. http://kb.parallels.com/de/762) die suexec2 Version von Plesk nach /usr/sbin/ kopiert (die sagt übrigens zu suexec2 -V _garnix_) und schon schmeisst suexec mit

Code: Select all

command not in docroot (/usr/bin/php-cgi5)
um sich. Was soll denn daß? Ok, man könnte jetzt sagen, damit verhält es sich total richtig und die Tatsache, daß es auf dem alten Server läuft ist non-compliant (...aber non-compliant kriegt man bei Plesk wohl umsonst dazu). Also hab ich eigene Wrapper unter /srv/www/ erstellt und die suexec2 genommen, die mit Apache kommt. Damit kann ich nun mod_cgi und mod_fcgid (2.3.5 hab ich hier installiert) nutzen. Da ich zudem auf mpm-worker umgestiegen bin, habe ich mod_php verb(r)annt.

Nun laufen bereits die mysql-DB's von 2 Präsenzen über den neuen Server und eine Domain ist komplett umgezogen. Ich werde nun nach und nach die anderen Präsenzen zuerst lokal testen und dann den DNS umstellen.

Achja, dabei hab ich auch gelernt, wie man einen eigenen Primary DNS vernünftig einrichtet. Dabei hat mir ein alter Beitrag aus diesem Forum sehr geholfen =D>

Zum Thema zurück: Ich kann jedem für seine Datensicherung duply nur wärmstens empfehlen.
Last edited by m.m. on 2010-03-08 15:52, edited 7 times in total.