{"id":11426,"date":"2023-11-07T21:00:00","date_gmt":"2023-11-07T19:00:00","guid":{"rendered":"https:\/\/u-labs.de\/portal\/?p=11426"},"modified":"2023-11-08T01:27:59","modified_gmt":"2023-11-07T23:27:59","slug":"warum-ihr-sicherungen-nie-ins-daten-verzeichnis-einer-anwendung-legen-solltet","status":"publish","type":"post","link":"https:\/\/u-labs.de\/portal\/warum-ihr-sicherungen-nie-ins-daten-verzeichnis-einer-anwendung-legen-solltet\/","title":{"rendered":"Warum ihr Sicherungen nie ins Daten-Verzeichnis einer Anwendung legen solltet (auch nicht testweise)"},"content":{"rendered":"

Ich wollte etwas ausprobieren und davor eine MariaDB-Datenbank sichern. In \/var\/lib\/mysql<\/strong> speichert MariaDB die angelegten Datenbanken, daher existierte dort bereits ein Volume – die Sicherung w\u00e4re also nach dem Neustart des Containers nicht verloren gewesen. Da ich sie nicht dauerhaft brauchte, aber nicht riskieren wollte, sie nach einem Neustart zu verlieren, legte ich sie tempor\u00e4r dort ab. In einen Unterordner, den ich mit Unterstrich-Suffix benannte, damit klar war, der Ordner ist nicht von MySQL verwaltet.<\/p>\n

Auf dem Datenbankserver fiel sp\u00e4ter beim Upgrade eine seltsam benannte Datenbank namens #mysql50#_backup-nextcloud-11.05.2023<\/strong> auf:<\/p>\n

\n
\"\"<\/a><\/figure>\n<\/div>\n

Konnte ich mir nicht erkl\u00e4ren und war verwundert, dass Rauten \u00fcberhaupt als Datenbankname zul\u00e4ssig sind – da musste etwas bei der Sicherung schief gelaufen sein. Es steckte aber mehr dahinter, als eine Datenbank, die keiner braucht. Das Upgrade des Servers lief wegen genau dieser Datenbank auf Fehler: <\/p>\n

mysql_upgrade -u root -p$MYSQL_ROOT_PASSWORD\nMajor version upgrade detected from 10.3.11-MariaDB to 10.5.22-MariaDB. Check required!\nPhase 1\/7: Checking and upgrading mysql database\nProcessing databases\nmysql\nmysql.column_stats                                 OK\nmysql.columns_priv                                 OK\nmysql.db                                           OK\nmysql.event                                        OK\nmysql.func                                         OK\nmysql.gtid_slave_pos                               OK\nmysql.help_category                                OK\nmysql.help_keyword                                 OK\nmysql.help_relation                                OK\nmysql.help_topic                                   OK\nmysql.host                                         OK\nmysql.index_stats                                  OK\nmysql.innodb_index_stats                           OK\nmysql.innodb_table_stats                           OK\nmysql.plugin                                       OK\nmysql.proc                                         OK\nmysql.procs_priv                                   OK\nmysql.proxies_priv                                 OK\nmysql.roles_mapping                                OK\nmysql.servers                                      OK\nmysql.table_stats                                  OK\nmysql.tables_priv                                  OK\nmysql.time_zone                                    OK\nmysql.time_zone_leap_second                        OK\nmysql.time_zone_name                               OK\nmysql.time_zone_transition                         OK\nmysql.time_zone_transition_type                    OK\nmysql.transaction_registry                         OK\nmysql.user                                         OK\nPhase 2\/7: Installing used storage engines... Skipped\nPhase 3\/7: Fixing views\nmariadb-check: Got error: 1102: Incorrect database name '#mysql50#_backup-nextcloud-11.05.2023' when selecting the database\nFATAL ERROR: Upgrade failed<\/code><\/pre>\n
Ein paar Wochen sind vergangen und dass ich den SQL-Dump h\u00e4ndisch tempor\u00e4r in \/var\/lib\/mysql<\/strong> abgelegt hatte, war vergessen. Ich vermutete daher, die Datenbank wohl mal dupliziert zu haben und dabei durch einen Fehler die Sonderzeichen im Name gelandet sind. Die Sicherung wurde ohnehin nicht mehr gebraucht, also wollte ich sie bei der Gelegenheit gleich entfernen – was MariaDB nicht akzeptierte:<\/p>\n
MariaDB [(none)]> drop database `#mysql50#_backup-nextcloud-11.05.2023`;\nERROR 1102 (42000): Incorrect database name '#mysql50#_backup-nextcloud-11.05.2023'<\/code><\/pre>\n
Rauten sind also doch nicht erlaubt, aber sie m\u00fcssen ja irgendwie rein gekommen sein. DBeaver versuchte es mit DROP SCHEMA<\/code>, was jedoch zum gleichen Fehler f\u00fchrte. Maskieren\/Escapen half ebenfalls nicht.  Ich schaute daher im Datenverzeichnis von MariaDB was dort zu finden war und stie\u00df auf einen \u00e4hnlich benannten Ordner:<\/p>\n
find \/var\/lib\/mysql -name \\*backup\\*\n\/var\/lib\/mysql\/_backup-nextcloud-11.05.2023<\/code><\/pre>\n
In ihm liegen aber keine f\u00fcr MySQL \u00fcblichen Datenbankdateien, sondern nur ein SQL-Dump – in diesem Falle nextcloud.sql.<\/code> Da fiel mir die anfangs erw\u00e4hnte Sicherung wieder ein, die ich testweise dort abgelegt hatte. Der Datenbankserver hatte die SQL-Datei beim n\u00e4chsten Start geladen und mit #mysql50#<\/strong> Pr\u00e4fix kenntlich gemacht, dass es sich um keine echte<\/em> Datenbank handelte – sondern der selbstst\u00e4ndig geladene Export. Das war mir nicht bewusst. Wenngleich es zugegeben nat\u00fcrlich auch nicht die sauberste Idee war, in \/var\/lib\/mysql <\/code>selbst Daten abzulegen.<\/p>\n
L\u00f6sen lie\u00df sich das Problem durch herunterfahren des Datenbankservers und anschlie\u00dfendes L\u00f6schen des Ordners mit der Datenbanksicherung:<\/p>\n
rm -rf \/var\/lib\/mysql\/_backup-nextcloud-11.05.2023<\/code><\/pre>\n
Die nun endg\u00fcltig gelernte Lektion<\/h2>\n
Das erinnert mich an ein Problem mit HCL Connections, als ich testweise eine von WebSphere zu ladende Jar-Datei umbenannt habe, um sie als Sicherung f\u00fcr einen Test zu behalten: Es ging schief, weil WAS s\u00e4mtliche Dateien im Verzeichnis lud. Nachdem dies in \u00e4hnlicher Weise zum zweiten Mal passiert ist, lautet die gelernte Lektion nun definitiv: Keine Sicherungen mehr im gleichen Verzeichnis anzulegen, in dem eine Anwendung ihre Daten erwartet. Auch wenn man selbst denkt, dass es Filter auf bestimmte Pfade\/Endungen gibt – wenn man nicht selbst der Entwickler ist, wei\u00df man eben nicht zu 100%, ob das wirklich so ist.<\/p>\n
Und auch wenn es in vielen F\u00e4llen funktioniert: Ausnahmen best\u00e4tigen die Regel. Diese Ausnahmen fallen einem jetzt oder sp\u00e4ter potenziell auf die F\u00fc\u00dfe – damit verbringt man unn\u00f6tig einige Zeit. Falls man unter Docker nirgendwo ein zweites Volume f\u00fcr z.B. Backups angelegt hat, muss man im Zweifel zuerst den Container stoppen und eines anlegen.<\/p>\n
Um das abschlie\u00dfend noch klarzustellen, sind Rauten entgegen meiner Vermutung tats\u00e4chlich in Datenbanknamen erlaubt<\/a>. \u00dcberraschend viele k\u00f6nnen genutzt werden, wenn man sie mit den korrekten Anf\u00fchrungsstrichen maskiert. Beabsichtigt benennen w\u00fcrde ich so trotzdem keine Tabelle: Es ist eine weitere potenzielle Fehlerquelle aus der selben Art von Kategorie, die meistens funktionieren, bis man Zeit mit einer Ausnahme verbringt. Muss auch nicht wirklich sein – Buchstaben und Minus bzw. Unterstrich als Trennzeichen haben bisher v\u00f6llig ausreicht.<\/p>\n
\n
\"\"<\/a><\/figure>\n<\/div>\n","protected":false},"excerpt":{"rendered":"
Ich wollte etwas ausprobieren und davor eine MariaDB-Datenbank sichern. In \/var\/lib\/mysql speichert MariaDB die angelegten Datenbanken, daher existierte dort bereits ein Volume – die Sicherung w\u00e4re also nach dem Neustart des Containers nicht verloren gewesen. Da ich sie nicht dauerhaft brauchte, aber nicht riskieren wollte, sie nach einem Neustart zu verlieren, legte ich sie tempor\u00e4r …<\/p>\n","protected":false},"author":5,"featured_media":11506,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[78],"tags":[1090,339],"class_list":["post-11426","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-software","tag-mariadb","tag-mysql"],"_links":{"self":[{"href":"https:\/\/u-labs.de\/portal\/wp-json\/wp\/v2\/posts\/11426","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/u-labs.de\/portal\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/u-labs.de\/portal\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/u-labs.de\/portal\/wp-json\/wp\/v2\/users\/5"}],"replies":[{"embeddable":true,"href":"https:\/\/u-labs.de\/portal\/wp-json\/wp\/v2\/comments?post=11426"}],"version-history":[{"count":9,"href":"https:\/\/u-labs.de\/portal\/wp-json\/wp\/v2\/posts\/11426\/revisions"}],"predecessor-version":[{"id":11572,"href":"https:\/\/u-labs.de\/portal\/wp-json\/wp\/v2\/posts\/11426\/revisions\/11572"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/u-labs.de\/portal\/wp-json\/wp\/v2\/media\/11506"}],"wp:attachment":[{"href":"https:\/\/u-labs.de\/portal\/wp-json\/wp\/v2\/media?parent=11426"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/u-labs.de\/portal\/wp-json\/wp\/v2\/categories?post=11426"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/u-labs.de\/portal\/wp-json\/wp\/v2\/tags?post=11426"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}