Massive Probleme nach Recovery mit duplicity

Apache, Lighttpd, nginx, Cherokee
dawn
Posts: 64
Joined: 2006-01-05 11:32

Massive Probleme nach Recovery mit duplicity

Post by dawn » 2006-11-12 10:37

Hallöchen,

Nach einigen massiven Problemen entschied ich mich dazu meinen Server auf den Stand de letzen Backups zurückzuholen. Ich backupe täglich meinen Server mit duplicity (resp. ftplicity) auf einen Backup-Server. Das klappt auch wirklich prima. Nun kam der erste Härtetest mit dem Recovery. Nebenbei gesagt, ich benutze Debian Sarge im Zusammenhang mit Plesk 8.0.1.

Meine Exclude-Datei sieht folgendermasen aus:

Code: Select all

/dev 
/proc 
/sys 
/tmp 
/var/tmp 
/var/run


Ich habe per "ftplicity restore /tmp/backup" das Backup zurückgeholt (in der Rescue-Umgebung meines Hosting-Anbieters kann ich leider duplicity etc. nicht installieren)

Dann habe ich den Server im Resuce-Mode booten lassen. Ich habe die HD gemountet und alle Dateien/Verzeichnisse auf der HD gelöscht abgesehen von den Verzeichnissen welche ich beim Backup ausgeschlossen habe (siehe oben) und nat. dem /tmp Verzeichnis in dem sich das zurückgespielte Backup befand. Dann habe ich per move mein System von /tmp/backup nach / verschoben. Danach habe ich den Server neu gebootet was auch nach einiger Zeit geklappt hat.

Einige Dienste scheinen zu laufen, andere jedoch leider nicht. Auch kann ich nicht mehr auf Plesk zugreifen, die anderen Webseiten aber ansprechbar. Ich habe darum mal ins Syslog geschaut welches folgendermassen aussieht:

Code: Select all

Nov 12 00:47:29 domainname named[2076]: starting BIND 9.2.4 -t /var/named/run-root -c /etc/named.conf -u bind 
Nov 12 00:47:29 domainname named[2076]: using 1 CPU 
Nov 12 00:47:29 domainname named[2076]: loading configuration from '/etc/named.conf' 
Nov 12 00:47:29 domainname named[2076]: listening on IPv4 interface lo, 127.0.0.1#53 
Nov 12 00:47:29 domainname named[2076]: listening on IPv4 interface eth0, 217.20.117.30#53 
Nov 12 00:47:29 domainname named[2076]: listening on IPv4 interface eth0:1, 84.16.249.195#53 
Nov 12 00:47:29 domainname named[2076]: listening on IPv4 interface eth0:2, 84.16.249.196#53 
Nov 12 00:47:29 domainname named[2076]: command channel listening on 127.0.0.1#953 
Nov 12 00:47:29 domainname named[2076]: couldn't open pid file '/var/run/named/named.pid': File exists 
Nov 12 00:47:29 domainname named[2076]: exiting (due to early fatal error) 
Nov 12 00:47:29 domainname inetd[2160]: ftp/tcp: bind: Address already in use 
Nov 12 00:47:29 domainname inetd[2160]: /etc/inetd.conf:46: bad wait type 
Nov 12 00:47:29 domainname inetd[2160]: smtp/tcp: bind: Address already in use 
Nov 12 00:47:29 domainname inetd[2160]: /etc/inetd.conf:47: bad wait type 
Nov 12 00:47:29 domainname inetd[2160]: smtps/tcp: bind: Address already in use 
Nov 12 00:47:29 domainname inetd[2160]: /etc/inetd.conf:48: bad wait type 
Nov 12 00:47:29 domainname inetd[2160]: poppassd/tcp: bind: Address already in use 
Nov 12 00:47:31 domainname mysqld_safe[2215]: started 
Nov 12 00:47:32 domainname mysqld[2218]: ^G/usr/sbin/mysqld: File '/var/log/mysql/mysql-bin.1' not found (Errcode: 13) 
Nov 12 00:47:32 domainname mysqld[2218]: 061112  0:47:32 [ERROR] Could not use /var/log/mysql/mysql-bin for logging (error 13). Turning logging off for the whole duration of the MySQL server process. To turn it on again: fix the cause, shutdown the MySQL server and restart it. 
Nov 12 00:47:32 domainname mysqld[2218]: 061112  0:47:32 [ERROR] Aborting 
Nov 12 00:47:32 domainname mysqld[2218]: 
Nov 12 00:47:32 domainname mysqld[2218]: 061112  0:47:32 [Note] /usr/sbin/mysqld: Shutdown complete 
Nov 12 00:47:32 domainname mysqld[2218]: 
Nov 12 00:47:32 domainname mysqld_safe[2220]: ended 
Nov 12 00:47:37 domainname kernel: eth0: no IPv6 routers present 
Nov 12 00:47:38 domainname /etc/init.d/mysql[2283]: 0 processes alive and '/usr/bin/mysqladmin --defaults-file=/etc/mysql/debian.cnf ping' resulted in 
Nov 12 00:47:38 domainname /etc/init.d/mysql[2283]: ^G/usr/bin/mysqladmin: connect to server at 'localhost' failed 
Nov 12 00:47:38 domainname /etc/init.d/mysql[2283]: error: 'Can't connect to local MySQL server through socket '/var/run/mysqld/mysqld.sock' (111)' 
Nov 12 00:47:38 domainname /etc/init.d/mysql[2283]: Check that mysqld is running and that the socket: '/var/run/mysqld/mysqld.sock' exists! 
Nov 12 00:47:38 domainname /etc/init.d/mysql[2283]: 
Nov 12 00:47:38 domainname named[2341]: starting BIND 9.2.4 -t /var/named/run-root -c /etc/named.conf -u bind 
Nov 12 00:47:38 domainname named[2341]: using 1 CPU 
Nov 12 00:47:38 domainname named[2341]: loading configuration from '/etc/named.conf' 
Nov 12 00:47:38 domainname named[2341]: listening on IPv4 interface lo, 127.0.0.1#53 
Nov 12 00:47:38 domainname named[2341]: listening on IPv4 interface eth0, 217.20.117.30#53 
Nov 12 00:47:38 domainname named[2341]: listening on IPv4 interface eth0:1, 84.16.249.195#53 
Nov 12 00:47:38 domainname named[2341]: listening on IPv4 interface eth0:2, 84.16.249.196#53 
Nov 12 00:47:38 domainname named[2341]: command channel listening on 127.0.0.1#953 
Nov 12 00:47:38 domainname named[2341]: couldn't open pid file '/var/run/named/named.pid': File exists 
Nov 12 00:47:38 domainname named[2341]: exiting (due to early fatal error) 
Nov 12 00:47:38 domainname mysqld_safe[2393]: started 
Nov 12 00:47:38 domainname mysqld[2396]: ^G/usr/sbin/mysqld: File '/var/log/mysql/mysql-bin.1' not found (Errcode: 13) 
Nov 12 00:47:38 domainname mysqld[2396]: 061112  0:47:38 [ERROR] Could not use /var/log/mysql/mysql-bin for logging (error 13). Turning logging off for the whole duration of the MySQL server process. To turn it on again: fix the cause, shutdown the MySQL server and restart it. 
Nov 12 00:47:38 domainname mysqld[2396]: 061112  0:47:38 [ERROR] Aborting 
Nov 12 00:47:38 domainname mysqld[2396]: 
Nov 12 00:47:38 domainname mysqld[2396]: 061112  0:47:38 [Note] /usr/sbin/mysqld: Shutdown complete 
Nov 12 00:47:38 domainname mysqld[2396]: 
Nov 12 00:47:38 domainname mysqld_safe[2398]: ended 
Nov 12 00:47:44 domainname /etc/init.d/mysql[2461]: 0 processes alive and '/usr/bin/mysqladmin --defaults-file=/etc/mysql/debian.cnf ping' resulted in 
Nov 12 00:47:44 domainname /etc/init.d/mysql[2461]: ^G/usr/bin/mysqladmin: connect to server at 'localhost' failed 
Nov 12 00:47:44 domainname /etc/init.d/mysql[2461]: error: 'Can't connect to local MySQL server through socket '/var/run/mysqld/mysqld.sock' (111)' 
Nov 12 00:47:44 domainname /etc/init.d/mysql[2461]: Check that mysqld is running and that the socket: '/var/run/mysqld/mysqld.sock' exists! 
Nov 12 00:47:44 domainname /etc/init.d/mysql[2461]: 
Nov 12 00:47:44 domainname qmail: 1163288864.991761 status: local 0/10 remote 0/20 
Nov 12 00:48:05 domainname /usr/sbin/cron[2650]: (CRON) INFO (pidfile fd = 3) 
Nov 12 00:48:05 domainname /usr/sbin/cron[2651]: (CRON) STARTUP (fork ok) 
Nov 12 00:48:05 domainname /usr/sbin/cron[2651]: (drweb) WRONG FILE OWNER (crontabs/drweb) 
Nov 12 00:48:05 domainname /usr/sbin/cron[2651]: (CRON) INFO (Running @reboot jobs) 
Nov 12 00:48:07 domainname kernel: ip_tables: (C) 2000-2002 Netfilter core team 
Nov 12 00:48:07 domainname wdcollect[2679]: Language en-US is used for sending e-mail messages. 
Nov 12 00:48:07 domainname wdcollect[2679]: Failed to connect to database server during the startup. New attempts will be made if needed. 
Nov 12 00:48:07 domainname wdcollect[2679]: Server started. 
Nov 12 00:57:29 domainname inetd[2160]: poppassd/tcp: bind: Address already in use 
Nov 12 00:57:29 domainname inetd[2160]: smtps/tcp: bind: Address already in use 
Nov 12 00:57:29 domainname inetd[2160]: smtp/tcp: bind: Address already in use 
Nov 12 00:57:29 domainname inetd[2160]: ftp/tcp: bind: Address already in use 
Nov 12 00:58:08 domainname wdcollect[2679]: Connection to server has been established. 
Nov 12 00:58:08 domainname relaylock: /var/qmail/bin/relaylock: Unable to connect to the mysql database, relay will work in closed mode & white list will not work 
Nov 12 00:58:08 domainname relaylock: /var/qmail/bin/relaylock: mail from 127.0.0.1:32784 (localhost) 
Nov 12 00:58:08 domainname wdcollect[2679]: SMTP server error: 'relaylock: db_connect: failed to connect to database: Error: Can't connect to local MySQL server through socket '/var/run/mysqld/mysqld.sock' (111) System error 111: Connection refused 220 domainname.kicks-ass.net ESMTP' 
Nov 12 00:58:08 domainname wdcollect[2679]: Trying to send using another server. 
Nov 12 00:58:08 domainname wdcollect[2679]: Connection to SMTP server has been closed. 
Nov 12 00:58:08 domainname wdcollect[2679]: Failed to connect to all SMTP servers. 
Nov 12 00:59:08 domainname wdcollect[2679]: Connection to server has been established. 
Nov 12 00:59:08 domainname relaylock: /var/qmail/bin/relaylock: Unable to connect to the mysql database, relay will work in closed mode & white list will not work 
Nov 12 00:59:08 domainname relaylock: /var/qmail/bin/relaylock: mail from 127.0.0.1:32785 (localhost) 
Nov 12 00:59:09 domainname wdcollect[2679]: SMTP server error: 'relaylock: db_connect: failed to connect to database: Error: Can't connect to local MySQL server through socket '/var/run/mysqld/mysqld.sock' (111) System error 111: Connection refused 220 domainname.kicks-ass.net ESMTP' 
Nov 12 00:59:09 domainname wdcollect[2679]: Trying to send using another server. 
Nov 12 00:59:09 domainname wdcollect[2679]: Connection to SMTP server has been closed. 
Nov 12 00:59:09 domainname wdcollect[2679]: Failed to connect to all SMTP servers.
Irgendwie scheint ein grundlegendes Probleme vorhanden zu sein was wahrscheindlich losbar wäre, aber ich weiss nicht wo ich ansetzen soll. Kann mir irgend ein Spezi hier helfen, ich wäre echt super dankbar... Was kann ich tun, wo liegt der Fehler...? Soweit ich das sehe scheint es irgendwie mit /var/run zusammenzuliegen....

Besten Dank schonmal im Vorraus,
Dawn

Roger Wilco
Administrator
Administrator
Posts: 5924
Joined: 2004-05-23 12:53

Re: Massive Probleme nach Recovery mit duplicity

Post by Roger Wilco » 2006-11-12 12:09

Viele deiner Dienste denken, sie laufen schon. Außerdem scheinen die Rechte auf einige Verzeichnisse nicht zu stimmen (z. B. /var/log/mysql/). Einfach mal alle Dienste beenden, die übrig gebliebenen Prozesse von Hand killen, PID-Files aufräumen, Verzeichnisrechte und -besitzer korrigieren und die Dienste über die jeweiligen Initskripte neu starten.

dawn
Posts: 64
Joined: 2006-01-05 11:32

Re: Massive Probleme nach Recovery mit duplicity

Post by dawn » 2006-11-12 12:21

Vielen Dank für deine Antwort! :)

Eigentlich SOLLTEN alle rechte stimmen, der Server ist ja vorher auch problemlos gelofen.

/var/log/mysql hat folgende berechtigung:

Code: Select all

drwxr-s---  2 bind        adm         4096 2006-11-09 15:20 mysql
Was ich nicht verstehe (vielleicht habe ich was grundsätzliches nicht verstanden?): Wenn ich doch den Server neu starte werden doch alle Dienste auch neu gestartet, wiso wird dann zurückgegeben das die Dienste schon laufen. Ich mutmase ein wenig dass dies daher kommt weil die entsprechenden .pid Files im Verzeichnis /var/run vorhanden sind.
PID-Files aufräumen
= löschen? Habe ich auch schon versucht, aber nach einem Reboot habe ich exakt die gleichen Probleme wie vorher.

Irgendwie scheint ein grundlegender Fehler vorhanden zu sein welcher es nicht ermöglicht die Dienste zu inizialisieren, doch was dies genau ist, kann ich echt nicht sagen.. :(

Roger Wilco
Administrator
Administrator
Posts: 5924
Joined: 2004-05-23 12:53

Re: Massive Probleme nach Recovery mit duplicity

Post by Roger Wilco » 2006-11-12 12:28

Dawn wrote:Eigentlich SOLLTEN alle rechte stimmen, der Server ist ja vorher auch problemlos gelofen.

/var/log/mysql hat folgende berechtigung:

Code: Select all

drwxr-s---  2 bind        adm         4096 2006-11-09 15:20 mysql
Hier siehst du doch eindeutig, dass die Benutzerrechte nicht stimmen (außer dein mysqld läuft unter dem Benutzer bind). Vermutlich hast du die /etc/passwd neu angelegt bzw. nicht gesichert.
Dawn wrote:Wenn ich doch den Server neu starte werden doch alle Dienste auch neu gestartet, wiso wird dann zurückgegeben das die Dienste schon laufen. Ich mutmase ein wenig dass dies daher kommt weil die entsprechenden .pid Files im Verzeichnis /var/run vorhanden sind.
Ja, zum Beispiel. Die PID-Files könnten aber auch in einem anderen Verzeichnis liegen. Kommt auf den Dienst an bzw. dessen Konfiguration an.

dawn
Posts: 64
Joined: 2006-01-05 11:32

Re: Massive Probleme nach Recovery mit duplicity

Post by dawn » 2006-11-12 12:35

Hier siehst du doch eindeutig, dass die Benutzerrechte nicht stimmen (außer dein mysqld läuft unter dem Benutzer bind). Vermutlich hast du die /etc/passwd neu angelegt bzw. nicht gesichert.
Scheinbar läuft mysqld wirklich unter dem Benutzer bind (das sehe ich an den Log-Dateien welche in der Vergangenheit angelegt worden sind). Die /etc/passwd wurde 100% mitgesichert da keine entsprechende Meldung aufgetaucht ist während dem Backup, die Datei nicht exkludiert wurde und auch wieder vorhanden ist, sonst könnte ich ja nicht mit den alten Benutzern einloggen (wenn ich das richtig sehe).

Wenn ich mit der ersten Fehlermeldung "couldn't open pid file '/var/run/named/named.pid': File exists" beginne scheint ja hier schon etwas nicht zu stimmen. Wenn /var/run leer ist sollten die verschiedenen Dienste doch automatisch ihre .pid-Files wieder erstellen?

Roger Wilco
Administrator
Administrator
Posts: 5924
Joined: 2004-05-23 12:53

Re: Massive Probleme nach Recovery mit duplicity

Post by Roger Wilco » 2006-11-12 12:40

Dawn wrote:Wenn ich mit der ersten Fehlermeldung "couldn't open pid file '/var/run/named/named.pid': File exists" beginne scheint ja hier schon etwas nicht zu stimmen. Wenn /var/run leer ist sollten die verschiedenen Dienste doch automatisch ihre .pid-Files wieder erstellen?
Das schon, aber nicht alle Initskripte überprüfen vorher, ob das Verzeichnis überhaupt existiert. Wenn /var/run/ bei dir leer ist, existiert /var/run/named/ nicht.

dawn
Posts: 64
Joined: 2006-01-05 11:32

Re: Massive Probleme nach Recovery mit duplicity

Post by dawn » 2006-11-12 12:52

Das stimmt, das habe ich auch schon bei der stundenlangen (mitlerweile Tagelangen) Suche durchs Internet herausgefunden. Ich habe darum alle Dateien in /var/run (per rm -R *) gelöscht aber dann noch mkdir (per mkdir /var/run/named) erstellt.

Trotzdem sehe ich im Syslog:

Code: Select all

couldn't open pid file '/var/run/named/named.pid': File exists
Wenn ich danach /var/run/named anschaue, sehe ich das sich darin keine PID-Datei befindet. Dann macht doch die Fehlermeldung im Syslog keinen Sinn?

Roger Wilco
Administrator
Administrator
Posts: 5924
Joined: 2004-05-23 12:53

Re: Massive Probleme nach Recovery mit duplicity

Post by Roger Wilco » 2006-11-12 13:01

Läuft dein Bind vielleicht in einer chroot-Umgebung? Dann schau darin nach. Im Zweifelsfall hilft `find / -name named.pid -type f`.

dawn
Posts: 64
Joined: 2006-01-05 11:32

Re: Massive Probleme nach Recovery mit duplicity

Post by dawn » 2006-11-12 13:03

Oder mal eine grundsätzliche Frage: Ist ein Backup eines laufenden Servers per duplicity (im Zusammenhang mit ftplicity) wirklich nicht einsetzbar?

Ich habe mich strikt an die Anleitung gehalten, welche ich in c't 13/2006 (S. 216) gefunden habe. Dort wird ein Recovery direkt aus dem Rescue-System durchgeführt. Doch das geht bei mir wie gesagt leider nicht, da ich duplicity nicht installieren kann.

Dort steht noch "In /mnt/dev müssen Sie auch gemäss der Dokumentation Ihrer Distribution" die Gerätedateien wiederherstellen, falls das System kein devfs verwendet.". Das habe ich nicht getan (weiss ehrlich gesagt auch nicht wie, aber ich habe Das Verzeichnis, wie auch schon gesagt, aber auch nicht gelöscht. An dem kanns nicht liegen oder?

dawn
Posts: 64
Joined: 2006-01-05 11:32

Re: Massive Probleme nach Recovery mit duplicity

Post by dawn » 2006-11-12 13:12

Ich habe den Befehl den du genannt hast mit folgendem Resultat ausgeführt:

Code: Select all

-rw-r--r--  1 drweb bind 5 2006-11-09 15:20 named.pid
Das ist eine Datei welche vor dem Restore schon vorhanden war. Sonst wird kein named.pid gefunden.

Ich weiss nicht ob es was hilft, aber ich nutze auf dem Server das Control-Panel Plesk 8.0.1.

EDIT: Das genannte named.pid befindet sich unter /var/named/run-root/var/run/named/named.pid