KeyHelp Community

Hallo, kurze Frage.

Beim wiederherstellen eines Backups werden mir diese Ordner vorgeschlagen:

/etc/
/home/keyhelp
/home/users/mrcrossii/
/root/
/var/spool/cron/


welche davon brauche ich wirklich?

Ich habe vorhin eine Wiederherstllung gemacht mit allen Ordnern und dann kam

MySQL - Connection Error: Access denied for user 'keyhelp'@'localhost' (using password: YES)

Kommt drauf an, was du wiederherstellen möchtest.

Die angezeigten Ordner zeigen den Inhalt des angefertigten Backups an. Diese und deren Unterordner sind im Backup enthalten.

Alexander wrote: ↑Fri 6. Mar 2026, 09:13 Kommt drauf an, was du wiederherstellen möchtest.

Die angezeigten Ordner zeigen den Inhalt des angefertigten Backups an. Diese und deren Unterordner sind im Backup enthalten.

ich habe z.B: den Ordner "cron" weiderhergestellt, aber sehe tortzdem keine geplanten Aufgaben

Edit: habe den Server bereits neugestartet

Hallo,

das ist normal. Keyhelp liest ja nicht manuell angelegte Cronjobs ein. Der Cron existiert dann nicht in der Keyhelp-Datenbank und wird daher nicht angezeigt. Also musst du wenn die Keyhelp Datenbank ebenfalls wiederherstellen

Florian wrote: ↑Fri 6. Mar 2026, 09:56 Hallo,

das ist normal. Keyhelp liest ja nicht manuell angelegte Cronjobs ein. Der Cron existiert dann nicht in der Keyhelp-Datenbank und wird daher nicht angezeigt. Also musst du wenn die Keyhelp Datenbank ebenfalls wiederherstellen

Vielen Dank

Eine kurze Frage noch

Woher kommt der Fehler, wenn man alle Ordner wiederherstellt?

MySQL - Connection Error: Access denied for user 'keyhelp'@'localhost' (using password: YES)

Hallo,

wenn du das auf einem frisch installierten System machst stimmen die Passwörter in den Konfigdatein nicht mehr mit denen überein die im Datenbankserver gesetzt sind. Daher gibt es ja in der Anleitung den Schritt die aktuellen Datenbankpasswörter zu sichern und die Anweisung den Ordner /etc an einer anderen Stelle wiederherzustellen.

Ah okay, danke



Kann man das DB Backup über Keyhelp so einstellen, dass es mit utf8mb4 exportiert und importiert wird? Aktuell ist es nur utf 8 und das hat alle Emojis in Beiträgen der Nutzer zerstört

Welche Collation hat denn die originale Datenbank? KeyHelp nimmt keine hier keine Änderung vor.

Alexander wrote: ↑Fri 6. Mar 2026, 15:16 Welche Collation hat denn die originale Datenbank? KeyHelp nimmt keine hier keine Änderung vor.

das kann ich tatsächlich nicht mehr nachvollziehen, weil die Backups vor meinem Server Absturz gemacht wurden


aktuell ist es utf8mb4_unicode_ci und ich hab da auch bei dem alten Server nie was dran geändert

Edit:

kann ich das in der alten SQL Datei sehen? Ich kann ja ein altes Backup als SQL Datei wiederherstellen, würde das helfen?

utf8mb4_unicode_ci hört sich doch korrekt an.

kann ich das in der alten SQL Datei sehen? Ich kann ja ein altes Backup als SQL Datei wiederherstellen, würde das helfen?

Dort könntest du sehen, welche Collation verwendet wird, ja.

Alexander wrote: ↑Fri 6. Mar 2026, 16:36 utf8mb4_unicode_ci hört sich doch korrekt an.

kann ich das in der alten SQL Datei sehen? Ich kann ja ein altes Backup als SQL Datei wiederherstellen, würde das helfen?

Dort könntst du sehen, welche Collation verwendet wird, ja.

Also die entsprechende Tabelle wurde richtig erstellt

ganz oben steht:

CREATE DATABASE /*!32312 IF NOT EXISTS*/ `queermeet_prod` /*!40100 DEFAULT CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci */;

der "posts" table:

DROP TABLE IF EXISTS `posts`;
/*!40101 SET @saved_cs_client = @@character_set_client */;
/*!40101 SET character_set_client = utf8mb4 */;
CREATE TABLE `posts` (
`id` int(11) NOT NULL AUTO_INCREMENT,
`user_id` int(11) NOT NULL,

Ansonsten steht ganz oben:

/*!40101 SET NAMES utf8 */;

Aber das ist das einzige Vorkommen, ansonsten steht überall

utf8mb4

Aber im Abschnitt

LOCK TABLES `posts` WRITE;
/*!40000 ALTER TABLE `posts` DISABLE KEYS */;
INSERT INTO `posts` VALUES

Steht

(216,18,'? Hat ein neues Profilbild hochgeladen!',NULL,NULL,NULL,'avatar','public',0,NULL,NULL,1,4,0,'2025-12-25 22:12:43','2025-12-28 23:49:48',NULL,NULL,NULL),

Eigentlich müsste das ein emoji sein

z.B. das Peace Emoji wurde richtig übernommen

(511,7000059,59,'Und jetzt gute Nacht ','text',NULL,0,NULL,'2024-06-15 20:23:30'),

Und ich habe das jetzt mal getestet

In PHPMyAdmin ist Zeichensatz/Kollation der Verbindung zum Server: auf utf8mb4_unicode_ci gestellt und ich habe ein aktuelles Backup erstellt

Mein Test Beitrag war

Ergebnis in DB Export:

(478,345,'?????',NULL,NULL,NULL,'text','public',0,NULL,NULL,1,0,0,'2026-03-06 16:14:00','2026-03-06 16:14:00',NULL,NULL,NULL);

Edit:

Wenn ich den Export der SQL direkt über phpmyadmin mache, werden emojis richtig exportiert, nur beim Backup über Keyhelp nicht


Export über phpmyadmin direkt:

(479, 7, '', NULL, NULL, NULL, 'text', 'public', 0, NULL, NULL, 1, 0, 0, '2026-03-06 16:23:59', '2026-03-06 16:23:59', NULL, NULL, NULL);

Ist das also doch ein Fehler?

Ich konnte es jetzt reproduzieren. Prüfe gerade, woran es liegt.

EDIT: Habs gefunden, Ich mach den Patch jetzt fertig. Dieser geht über Konfiguration -> Patchmanager im Laufe des Tages online.

Bei bereits bestehenden Backups sollte es ausreichen im SQL Dump statt zu verwenden

Edit 2: Patch ist live.