LXC Backup/Restore auf anderem Host

[naibed]

Hallo zusammen,

Ich hoffe mir kann hier jemand Lösungsansätze geben.
Ich habe einen neuen Proxmox 5.2 Server installiert, ich möchte meine LXC Maschinen und VM's vom 1.ten Proxmox 5.2 auf den 2.ten packen. Hier bin ich folgendermaßen vorgegangen.

1.ten Proxmox 5.2 Server Webinterface:
LXC Container heruntergefahren.
Backup der LXC Maschine gestartet mit den Optionen (Modus: Stopp / Kompression: GZIP (gut))
Backup wurde auf eine USB Platte geschrieben.

2.ten Proxmox 5.2 Server:
Auf diesem Server habe ich das tar.gz File von der USB Platte über den Zugrückspielen Button wiederherstellt.
Alles ohne Fehler oder Probleme.

Die LXC Maschine ist ein Apache Webserver mit PHP7 und Mariadb auf basis von Debian 9 für einen Wordpress Blog.

Ressourcen:

• root-disk (/),
  
• Mount Point (var/lib/mysql),
• Mount Point (/var/www)

Wenn ich den wiederhergestellten LXC Container auf dem 2.ten Proxmox Server starte erhalte ich über die URL die Fehlermeldung "Fehler beim Aufbau der Datenbankverbindung"
Im syslog sehe ich Fehler wie

• "Can't create test file /var/lib/mysql/blog.lower-test" ,
  
• "Failed to set devices.allow on /system.slice/mariadb.service: Operation not permitted"
• mariadb.service: Failed with result 'exit-code'.

Ich habe im Internet nach solchen Fehler gesucht und habe nur etwas für die Version 4.2 gefunden das ich in der Datei /etc/vzdump.conf den Eintrag stdexcludes: 0 erweitern soll.
Der Fehler soll mit den Log Dateien zusammen hängen aber ich verstehe nicht warum.

Ich bin über jede Hilfe dankbar.

Gruß
Naibed

 

[fireon]

Hmm, seltsamer Fehler. Und du hast auch die Datenlaufwerke am Zielhost? Da du ja wie du geschrieben hast Mountpoints hast. Poste doch bitte mal dein Config des Containers:

pct config <id>

 

[naibed]

Hallo Fireon,

Das Backup wird auf dem 2.ten Proxmox komplett hergestellt, root laufwerk und mp's.
Es sind in den mp's alle Dateien vorhanden, wie in der Quelle.
Die config sieht auf beiden Hosts genau gleich aus.

Ich habe auch zwei Kollegen von mir gefragt ob sie auf ihrer Proxmox Maschinen das Problem kurz nachstellen können und mir berichten ob sie den gleichen Fehler feststellen können.
Das Ergebnis war leider nicht ganz eindeutig :-( .
Bei einem taucht der gleiche Fehler auf und beim anderen nicht. (es wurde mit unterschiedlichen Webserver versucht.)
Alle Hosts sind auf dem gleichen Software Stand.

@fireon
Hier noch gewünschte config

arch: amd64
cores: 1
hostname: blog
memory: 512
mp0: local:203/vm-203-disk-2.raw,mp=/var/lib/mysql,backup=1,size=5G
mp1: raid:203/vm-203-disk-1.raw,mp=/var/www,backup=1,size=10G
net0: name=eth0,bridge=vmbr0,gw=192.168.1.1,hwaddr=4E:60:CF:E6:DE:47,ip=192.168.1.203/24,type=veth
onboot: 0
ostype: debian
rootfs: local:203/vm-203-disk-1.raw,size=8G
swap: 512

Gruß
naibed

 

[fireon]

Hmm, sehr strange... mach hier ja fast nur mit Container auf verschiedenen Hosts und Clustern und hatte das Problem noch nie. Den einzigen Unterschied den ich jetzt feststellen kann ist nur das wir immer mehr Cores als 1 und mehr RAM als 512MB zugewiesen haben, auch verwenden wir nur Ubuntu, da wir mit Debian schon immer ganz komische, nie nachvollziebare Dinge beobachtet haben. Versuch nur mal zum Test 2GB RAM und wenigstens 4 Cores zum zuweisen.

 

[naibed]

@fireon
Natürlich lasse ich die Server nicht mit 512MB RAM und 1 Core laufen, die config ist von meinen Tests.
Ich arbeite schon länger mit Proxmox und Debian größere Probleme konnte ich noch nie feststellen, außer dieses hier

ABER:
Ich denke ich habe das Problem gefunden.
Schuld bei der Wiederherstellung sind die Mountpoints.
Ich habe ja /var/lib/mysql als mp eingehängt, bei der wiederhergestellt habe ich kein Recht auf diesem Mountpoint die Datei "tc.log" zu erstellen die nötig ist um MariaDB zu starten.
Ich habe diesen Bug nachgestellt mit zwei neu installierten LXC.

Ich habe auf beide LXC Wordpress Standard installiert.
LXC1 (Wiederherstellung ohne Probleme):
rootfs 8GB

LXC2 (Wiederherstellung mit Fehler):
rootfs 8GB
mp (/var/lib/mysql): 2GB
mp (/var/www): 2GB

Falls jemand Zeit hat, und möchte das nachprüfen wäre ich über eine Rückmeldung sehr froh.


Gruß
naibed

 

[fireon]

Konnte da nachvollziehen. HIer auf Ubuntu 18.04

Failed to dump process list, ignoring: Input/output error
* mysql.service - MySQL Community Server
   Loaded: loaded (/lib/systemd/system/mysql.service; enabled; vendor preset: enabled)
   Active: failed (Result: exit-code) since Thu 2018-10-04 21:08:35 CEST; 2min 20s ago
  Process: 575 ExecStart=/usr/sbin/mysqld --daemonize --pid-file=/run/mysqld/mysqld.pid (code=exited, status=1/FAILURE)
  Process: 566 ExecStartPre=/usr/share/mysql/mysql-systemd-start pre (code=exited, status=0/SUCCESS)
    Tasks: 0 (limit: 4915)
   CGroup: /system.slice/mysql.service

Oct 04 21:08:35 testlamp systemd[1]: mysql.service: Failed to kill control group /system.slice/mysql.service, ignoring: Input/output error
Oct 04 21:08:35 testlamp systemd[1]: mysql.service: Failed with result 'exit-code'.
Oct 04 21:08:35 testlamp systemd[1]: Failed to start MySQL Community Server.
Oct 04 21:08:35 testlamp systemd[1]: mysql.service: Service hold-off time over, scheduling restart.
Oct 04 21:08:35 testlamp systemd[1]: mysql.service: Scheduled restart job, restart counter is at 10.
Oct 04 21:08:35 testlamp systemd[1]: Stopped MySQL Community Server.
Oct 04 21:08:35 testlamp systemd[1]: mysql.service: Start request repeated too quickly.
Oct 04 21:08:35 testlamp systemd[1]: mysql.service: Failed with result 'exit-code'.
Oct 04 21:08:35 testlamp systemd[1]: Failed to start MySQL Community Server.