Linux commando: mysqldump

Elke website die iets opslaat, slaat dat op in een database, en een database is het ene onderdeel van een server dat je niet kunt kopieren door een map te verslepen. De bestanden staan in een formaat dat alleen de database-engine begrijpt, ze veranderen terwijl je ze leest, en de helft van wat ertoe doet staat in geheugen dat nog niet naar schijf is geschreven. Als je een kopie van een MySQL- of MariaDB-database nodig hebt, kopieer je dus geen bestanden. Je vraagt de server om een reeks instructies uit te schrijven waarmee de database opnieuw is op te bouwen. Het programma dat die vraag stelt is mysqldump.

2. Waar komt de naam vandaan?

De naam is een simpele samenstelling, zonder verborgen grap:

mysqldump  =  MySQL  +  dump

De interessante helft is dump. In de informatica is een dump een volledige, onbewerkte uitdraai van een interne toestand: een core dump, een memory dump, een hex dump. Het woord draagt de belofte dat er niets is samengevat en niets is weggelaten. Dat is precies de belofte die dit programma over je tabellen doet.

Het schept ook de juiste verwachting over het formaat. Een dump is geen slim archief. Het is de inhoud, op de meest voor de hand liggende manier uitgeschreven, en daarom is de uitvoer leesbare SQL die je in een teksteditor kunt openen en om drie uur 's nachts met de hand kunt repareren.

MariaDB heeft het programma inmiddels hernoemd naar mariadb-dump, met dezelfde opbouw en een andere leveranciersnaam ervoor. Zie paragraaf 7.2.

4. Eenvoudige toepassingen

4.1 De eenvoudigst mogelijke dump

Noem een database. De SQL gaat naar je terminal:

$ mysqldump -u root -p sitedb

De vlag -u (kort voor user) noemt het account, en -p (kort voor password) laat het programma om het wachtwoord vragen. Doe dit een keer, kijk hoe de SQL voorbijrolt, en het gereedschap is niet mysterieus meer. Stuur het daarna door naar een bestand, zoals je het altijd zult gebruiken:

$ mysqldump -u root -p sitedb > sitedb.sql

Let op waar de omleiding staat. mysqldump schrijft naar standaarduitvoer, dus de shell maakt het bestand, niet het programma. Dat ene feit verklaart de meeste pipelines verderop in dit artikel, en de meeste valkuilen in paragraaf 7.3.

4.2 Lezen wat eruit komt

Hier is een echte dump van een kleine tabel, met het commentaarblok bovenaan weggelaten om ruimte te sparen:

$ mysqldump -u root -p --skip-dump-date sitedb j6_content

/*!40101 SET @OLD_CHARACTER_SET_CLIENT=@@CHARACTER_SET_CLIENT */;
/*!40101 SET NAMES utf8mb4 */;
/*!40103 SET @OLD_TIME_ZONE=@@TIME_ZONE */;
/*!40103 SET TIME_ZONE='+00:00' */;
/*!40014 SET @OLD_FOREIGN_KEY_CHECKS=@@FOREIGN_KEY_CHECKS, FOREIGN_KEY_CHECKS=0 */;

DROP TABLE IF EXISTS `j6_content`;
CREATE TABLE `j6_content` (
  `id` int(11) NOT NULL AUTO_INCREMENT,
  `title` varchar(255) NOT NULL,
  `alias` varchar(255) NOT NULL,
  `state` tinyint(4) NOT NULL DEFAULT 1,
  `created` datetime NOT NULL,
  PRIMARY KEY (`id`)
) ENGINE=InnoDB AUTO_INCREMENT=4 DEFAULT CHARSET=utf8mb4;

LOCK TABLES `j6_content` WRITE;
/*!40000 ALTER TABLE `j6_content` DISABLE KEYS */;
INSERT INTO `j6_content` VALUES
(1,'Welcome','welcome',1,'2026-08-01 10:00:00'),
(2,'About us','about-us',1,'2026-08-02 11:30:00'),
(3,'Draft post','draft-post',0,'2026-08-03 09:15:00');
/*!40000 ALTER TABLE `j6_content` ENABLE KEYS */;
UNLOCK TABLES;

Vijf dingen zijn het aanwijzen waard, want ze beantwoorden vragen die mensen voortdurend over dumps stellen.

• De /*!40101 ... */-opmerkingen zijn uitvoerbaar. Dit is de versiecommentaar-syntaxis van MySQL. Een gewone SQL-parser ziet commentaar en slaat het over; een MySQL-server van versie 4.01.01 of nieuwer haalt de markering weg en voert het statement erbinnen uit. Zo blijft een dumpbestand geschikt voor zowel oude als nieuwe servers.
• DROP TABLE IF EXISTS komt eerst. Terugzetten is met opzet destructief: het vervangt de tabel in plaats van erin samen te voegen. Zie paragraaf 9.
• De rijen zijn gebundeld. Een INSERT draagt meerdere VALUES-lijsten. Dat is --extended-insert, standaard aan, en het maakt terugzetten veel sneller dan een statement per rij.
• TIME_ZONE='+00:00' staat bovenaan. Je TIMESTAMP-kolommen worden in UTC gedumpt, zodat ze een verhuizing naar een server in een andere tijdzone overleven. Dit is --tz-utc, ook standaard aan.
• FOREIGN_KEY_CHECKS=0 staat er ook bovenaan. Tabellen worden weggeschreven in de volgorde waarin de server ze noemt, en dat is niet de volgorde van afhankelijkheden. Een kindrij kan dus makkelijk worden ingevoegd voordat de ouder waarnaar hij wijst bestaat. Door de controles voor de duur van het terugzetten uit te zetten, werkt dat toch. Aan het eind krijgen ze hun oude waarde terug, en de constraints zelf staan gewoon nog in de CREATE TABLE-statements - alleen de controle stond even stil. Paragraaf 6.3 laat de verwante truc zien die mysqldump voor views gebruikt.

4.3 Terugzetten: er is geen mysqlrestore

Mensen zoeken naar het bijbehorende terugzetcommando en vinden het niet. Het bestaat niet, en dat hoeft ook niet. De dump is een script van SQL-statements, dus je zet hem terug door hem aan de gewone client te voeren:

$ mysql -u root -p sitedb < sitedb.sql

De database zelf moet al bestaan, want een gewone dump van een database bevat geen CREATE DATABASE. Maak hem dus eerst aan:

$ mysql -u root -p -e "CREATE DATABASE sitedb CHARACTER SET utf8mb4"
$ mysql -u root -p sitedb < sitedb.sql

Merk op dat de doelnaam op de opdrachtregel van het terugzetten staat. Daardoor is het triviaal om een dump in een anders genoemde database terug te zetten, en precies zo kloon je een live site naar een staging-kopie.

4.4 Een tabel, meerdere tabellen, meerdere databases

De argumenten na de databasenaam zijn tabelnamen:

$ mysqldump -u root -p sitedb j6_content              # one table
$ mysqldump -u root -p sitedb j6_content j6_users     # two tables
$ mysqldump -u root -p --databases sitedb shopdb      # two whole databases
$ mysqldump -u root -p --all-databases                # everything on the server

De vlag --databases (-B) verandert de betekenis van elk argument: het worden allemaal databasenamen, en de uitvoer krijgt er per database een CREATE DATABASE en een USE-statement bij. Dat is een echt verschil in gedrag, niet alleen in schrijfwijze:

Gebruik dus de gewone vorm als je hem misschien ergens anders wilt terugzetten, en --databases als je een getrouwe, op zichzelf staande herbouw wilt.

4.5 Verbinden met de juiste server

De verbindingsvlaggen zijn dezelfde als voor de mysql-client:

$ mysqldump -h db.example.com -P 3306 -u backup -p sitedb > sitedb.sql

-h is de host, -P (hoofdletter P) is de poort, en -p (kleine letter) is het wachtwoord. De twee p-vlaggen door elkaar halen is een inwijdingsritueel. Nog een subtiliteit: op Linux betekent de host localhost "gebruik de lokale Unix-socket", terwijl 127.0.0.1 "gebruik TCP naar deze machine" betekent. Dat is niet hetzelfde, en als een dump strandt op een socketfout, is overschakelen naar 127.0.0.1 het eerste dat je probeert.

6. Gevorderde toepassingen

6.1 De standaarden die je nooit hebt ingesteld: --opt

Nieuwe gebruikers kopieren vaak een lang commando vol vlaggen zonder te weten dat de meeste al aanstaan. De verzameloptie --opt staat standaard aan en betekent acht dingen tegelijk:

mysqldump --opt sitedb is dus hetzelfde als mysqldump sitedb. Losse onderdelen zet je uit met het voorvoegsel --skip-, en allemaal tegelijk met --skip-opt.

Een paar is makkelijk te verwarren, en de namen liggen echt zo dicht bij elkaar:

• --lock-tables vergrendelt tabellen op de server, tijdens de dump. Dit is degene die je met --single-transaction uitzet.
• --add-locks schrijft LOCK TABLES-statements in het uitvoerbestand, om het latere terugzetten te versnellen. Het heeft geen enkel effect op de live server, en --single-transaction laat het gewoon aanstaan.

6.2 Een dump leesbaar maken: --compact

Als je een dump wilt lezen of vergelijken in plaats van terugzetten, zit de standaardtekst in de weg. --compact haalt die weg:

$ mysqldump -u root -p --compact --no-data sitedb j6_content

CREATE TABLE `j6_content` (
  `id` int(11) NOT NULL AUTO_INCREMENT,
  `title` varchar(255) NOT NULL,
  `alias` varchar(255) NOT NULL,
  `state` tinyint(4) NOT NULL DEFAULT 1,
  `created` datetime NOT NULL,
  PRIMARY KEY (`id`)
) ENGINE=InnoDB AUTO_INCREMENT=4 DEFAULT CHARSET=utf8mb4;

Het zet commentaar, de drop-statements, de locks, de indexafhandeling en de tekensetregels uit. Dat maakt het uitstekend om te lezen en ongeschikt als backup. Gebruik het niet voor de dump waar je echt op leunt.

6.3 De onderdelen die geen tabellen zijn

Een database is meer dan tabellen, en mysqldump behandelt de extra's niet allemaal hetzelfde. Dit pakt mensen lelijk, want de dump slaagt en ziet er compleet uit:

De scheefheid is niet vanzelfsprekend en er komt geen waarschuwing. Een database met stored procedures, gedumpt zonder --routines, levert een bestand op dat netjes terugkomt en ze mist:

$ mysqldump -u root -p --no-data sitedb | grep -c PROCEDURE
0
$ mysqldump -u root -p --no-data --routines sitedb | grep -c PROCEDURE
1

Als de kans bestaat dat de database routines of events heeft, dump dan met allebei de vlaggen. Ze kosten niets als er niets te dumpen valt.

Views gaan ongevraagd mee, maar ze worden op een manier weggeschreven die de eerste keer op een bug lijkt. Elke view verschijnt twee keer. Een keer op zijn alfabetische plek tussen de tabellen, als plaatshouder van nepkolommen:

--
-- Temporary table structure for view `v_published`
--
DROP TABLE IF EXISTS `v_published`;
/*!50001 DROP VIEW IF EXISTS `v_published`*/;
/*!50001 CREATE VIEW `v_published` AS SELECT
 1 AS `id`,
  1 AS `title` */;

En dan nog een keer, helemaal aan het eind van het bestand, als het echte werk:

--
-- Final view structure for view `v_published`
--
/*!50001 DROP VIEW IF EXISTS `v_published`*/;
/*!50001 CREATE ALGORITHM=UNDEFINED */
/*!50013 DEFINER=`root`@`localhost` SQL SECURITY DEFINER */
/*!50001 VIEW `v_published` AS select `j6_content`.`id` AS `id`,
    `j6_content`.`title` AS `title` from `j6_content` */;

Dit is opnieuw de volgorde van terugzetten, hetzelfde probleem dat de foreign-keyschakelaar oplost. Een view selecteert uit tabellen die op dat punt in het bestand misschien nog niet bestaan, en een andere view selecteert misschien uit deze view. De plaatshouder geeft alles wat naar de view verwijst iets geldigs om aan te haken terwijl de tabellen nog worden aangemaakt, en de echte definitie vervangt hem zodra ze er allemaal zijn. Beide helften zijn nodig, dus ruim die SELECT 1 AS ...-blokken niet op uit een dump die je wilt terugzetten.

6.4 Binaire gegevens: --hex-blob

Standaard worden BLOB- en BINARY-kolommen als ontsnapte tekstliteralen weggeschreven. Meestal overleeft dat de heenreis en terug, maar binaire bytes binnen een aanhalingsteken zijn kwetsbaar: een ongelukkige bytereeks, een tekensetconversie tijdens het terugzetten, of een editor die regeleindes "repareert" kan ze stilzwijgend beschadigen. --hex-blob schrijft ze in plaats daarvan als hexadecimale 0x-literalen, die niet verkeerd te lezen zijn:

$ mysqldump --single-transaction --hex-blob -u root -p sitedb > sitedb.sql

Het bestand wordt groter. Als de database afbeeldingen, pdf's of geserialiseerde binaire gegevens opslaat, zet de vlag er dan toch bij.

6.5 Grote waarden en max_allowed_packet

Een rij moet in een enkel pakket tussen server en client oversteken, en beide kanten begrenzen hoe groot dat pakket mag zijn. Als een waarde groter is dan die grens, stopt de dump - met een foutmelding die mensen op een volstrekt verkeerd spoor zet:

$ mysqldump --max-allowed-packet=1M -u root -p sitedb big > big.sql
mysqldump: Error 2013: Lost connection to server during query
           when dumping table `big` at row: 0
$ echo $?
3

Er is niets verloren gegaan en het netwerk is in orde. De rij paste simpelweg niet. De client meldt een verbroken verbinding omdat dat werkelijk is wat hij ziet als de server een te groot pakket weigert, en beheerders raken daar elk jaar middagen aan kwijt. De aanwijzing is at row: 0 op een tabel waarvan je weet dat er grote waarden in zitten.

De standaard van de client is ruim, maar niet onbeperkt: 16 MB op MySQL 8.0, 24 MB op MariaDB. Verhoog hem als een tabel afbeeldingen, pdf's of lange TEXT bevat:

$ mysqldump --single-transaction --hex-blob --max-allowed-packet=512M \
    -u root -p sitedb > sitedb.sql

Denk daarna aan de andere kant. Een dump die alleen met een verhoogde grens gemaakt kon worden, heeft dezelfde ruimte nodig om teruggezet te worden, dus de max_allowed_packet van de doelserver moet ook groot genoeg zijn. Anders schrijft de backup zich prima weg en weigert hij te laden, en dat ontdek je op de dag dat je hem nodig hebt.

6.6 Uitvoer met tabs: --tab

De optie -T / --tab schrijft per tabel twee bestanden in een map: een .sql-bestand met de definitie en een .txt-bestand met de ruwe rijen.

$ mysqldump -u root -p --tab=/var/lib/mysql-files/out sitedb j6_content
$ ls /var/lib/mysql-files/out/
j6_content.sql  j6_content.txt

$ cat /var/lib/mysql-files/out/j6_content.txt
1	Welcome	welcome	1	2026-08-01 10:00:00
2	About us	about-us	1	2026-08-02 11:30:00
3	Draft post	draft-post	0	2026-08-03 09:15:00

Dat terugladen met LOAD DATA INFILE gaat veel sneller dan INSERT-statements afspelen, en de .txt-bestanden gaan zo andere gereedschappen in. Maar er zijn twee harde beperkingen, en daarom gebruiken de meeste mensen het nooit: mysqldump moet op dezelfde machine draaien als de server, want de server schrijft de databestanden zelf, en de server heeft schrijfrechten nodig op de doelmap (meestal die uit secure_file_priv). Het is een lokaal bulkoverdrachtgereedschap, geen backupmethode.

6.7 Replicatiecoördinaten

Om een replica uit een dump op te bouwen, moet de dump de exacte positie in het binaire log vastleggen waarop hij is gemaakt. Modern MySQL noemt dat --source-data:

$ mysqldump --single-transaction --source-data=2 \
    -u root -p --all-databases > full.sql

Waarde 1 schrijft een uitvoerbaar CHANGE MASTER-statement; 2 schrijft het als commentaar, en dat is wat je wilt als je alleen een backup maakt en niet wilt dat terugzetten de replicatie herconfigureert. Samen met --single-transaction wordt de globale leeslock alleen kort aan het begin vastgehouden in plaats van de hele dump lang.

De oudere namen werken nog, maar geven nu een melding dat ze verouderd zijn. De vertaling is:

Denk op een server met GTID's aan ook aan --set-gtid-purged. De standaard is AUTO, en die zet een SET @@GLOBAL.GTID_PURGED-statement in de dump. Dat is juist als je een replica bouwt en fout als je een kopie van de site in een stagingserver terugzet, waar het zal weigeren te laden of de GTID-toestand van het doel bederft. Gebruik voor een gewone backup --set-gtid-purged=OFF.

6.8 Het wachtwoord van de opdrachtregel houden

-pSecret123 schrijven zet het wachtwoord in je shellgeschiedenis en in de proceslijst, waar elke gebruiker op de machine het met ps kan lezen. De client van MySQL waarschuwt je er elke keer voor:

$ mysqldump -u root -pSecret123 sitedb > sitedb.sql
mysqldump: [Warning] Using a password on the command line interface can be insecure.

De client van MariaDB drukt die waarschuwing niet af, waardoor de gewoonte makkelijker vol te houden is en geen haar minder gevaarlijk. Zet de inloggegevens voor scripts in een bestand dat alleen de eigenaar kan lezen:

$ cat ~/.my.cnf
[client]
user = backup
password = Secret123

$ chmod 600 ~/.my.cnf
$ mysqldump --single-transaction sitedb > sitedb.sql   # no credentials needed

Nog beter voor een cronjob: houd het in een eigen bestand en wijs er uitdrukkelijk naar, zodat je niet afhankelijk bent van de gebruiker onder wie de taak toevallig draait:

$ mysqldump --defaults-extra-file=/etc/backup/db.cnf \
    --single-transaction sitedb > sitedb.sql

Die vlag moet vooraan op de opdrachtregel staan. MySQL biedt ook mysql_config_editor, dat inloggegevens versluierd in ~/.mylogin.cnf bewaart voor gebruik met --login-path. Versluierd is niet versleuteld - het houdt iemand tegen die over je schouder meekijkt, niet een aanvaller die het bestand heeft.

6.9 Een backupgebruiker met alleen de rechten die nodig zijn

Een backuptaak heeft geen root nodig. Geef hem precies de rechten die een dump gebruikt:

CREATE USER 'backup'@'localhost' IDENTIFIED BY 'a-long-random-password';
GRANT SELECT, SHOW VIEW, TRIGGER, LOCK TABLES, EVENT, PROCESS
  ON *.* TO 'backup'@'localhost';
FLUSH PRIVILEGES;

Elk recht hoort bij iets wat het gereedschap doet: SELECT om rijen te lezen, SHOW VIEW om views te reproduceren, TRIGGER voor triggers, LOCK TABLES voor het standaardvergrendelen, EVENT voor --events, en PROCESS omdat MySQL 8.0 dat nodig heeft om tablespace-informatie te lezen. Dump je nooit events, laat EVENT dan weg. Weigert je hoster PROCESS, zet dan --no-tablespaces bij het commando en heb je het niet meer nodig.

6.10 Het draaien tegen een Docker-container

De meeste lokale ontwikkeling gebeurt tegenwoordig in containers, en dat voegt een rimpel toe die het begrijpen waard is. De databaseserver draait binnen de container, terwijl je shell, je omleiding en het dumpbestand allemaal buiten de container leven. Elk probleem in deze paragraaf komt voort uit die ene grens.

Dumpen is de makkelijke richting. Noem de service precies zoals hij in je docker-compose.yml staat en leid om zoals altijd:

$ docker compose exec -T db mysqldump --single-transaction \
    -u root -p sitedb > sitedb.sql

Bij terugzetten verliezen mensen een avond:

$ docker compose exec db mysql -u root -p sitedb < sitedb.sql
the input device is not a TTY

Er wordt niets teruggezet. De oplossing is de vlag -T, en de reden is het begrijpen waard in plaats van uit je hoofd leren. Standaard wijst docker compose exec een pseudoterminal toe, alsof je het commando interactief had getypt. Een terminal is geen pipe: die draagt geen bestand op standaardinvoer. -T betekent "geen terminal", en dat laat de omleiding erdoor.

Gewoon docker exec heeft hetzelfde probleem, andersom gespeld. Het wijst geen terminal toe, maar het koppelt ook geen standaardinvoer tenzij je erom vraagt met -i:

$ docker exec CONTAINER mysql -u root -p sitedb < dump.sql     # does nothing
$ docker exec -i CONTAINER mysql -u root -p sitedb < dump.sql  # correct

De eerste vorm is verreweg de gevaarlijkste van de twee, want die drukt helemaal geen fout af. Het commando keert terug, de database is onaangeroerd, en nergens hoor je dat het terugzetten niet is gebeurd.

Je vindt genoeg advies dat je -T ook bij de dump moet zetten, omdat het bestand anders met Windows-regeleindes terugkomt. Op Compose v2 klopt dat niet meer: die wijst alleen een terminal toe als de uitvoer echt naar een terminal gaat, dus een omleiding of een pipe is al veilig. Voor de interactieve client houd ik een klein wrapperscript aan dat op [ -t 0 ] test en alleen -T toevoegt als standaardinvoer geen terminal is. Hetzelfde commando geeft me dan een echte SQL-prompt als ik die wil, en slikt een dumpbestand als ik er een in voer.

Er is nog een valkuil die eigen is aan containers, en dat is het naamprobleem uit paragraaf 7.2 met aanzienlijk scherpere tanden. De client binnen de container is degene die de image meelevert, niet die op je laptop. Wijs een compose-bestand naar mariadb:11.4 en de vertrouwde naam is verdwenen:

$ docker compose exec -T db mysqldump -u root -p sitedb > sitedb.sql
$ echo $?
127

Kijk nu naar de backup die dat commando zojuist heeft opgeleverd:

$ ls -l sitedb.sql
-rw-r--r-- 1 peter peter 137 Aug 23 11:04 sitedb.sql

$ cat sitedb.sql
OCI runtime exec failed: exec failed: unable to start container process:
exec: "mysqldump": executable file not found in $PATH: unknown

Docker heeft zijn eigen foutmelding in je dumpbestand geschreven. Het bestand bestaat, het is niet leeg, en de datum is van vandaag, dus een backupcontrole die alleen op een omvang groter dan nul test, accepteert het zonder klagen. Gebruik mariadb-dump voor MariaDB 11-images, en lees paragraaf 7.3 nog eens: dit is het lege-backupprobleem met een andere hoed op.

Tot slot de inloggegevens. Een compose-stack houdt ze meestal al in het .env-bestand, dus er is geen reden om een wachtwoord op de opdrachtregel te typen en aan je shellgeschiedenis te geven:

$ docker compose exec -T db mysqldump --single-transaction \
    -u"$MYSQL_USER" -p"$MYSQL_PASSWORD" "$MYSQL_DATABASE" > sitedb.sql

Wees eerlijk over wat je daarmee koopt. Het houdt het wachtwoord uit je geschiedenis en uit het script, maar het wachtwoord is nog steeds zichtbaar in de proceslijst binnen de container. Op een lokale ontwikkelstack is dat een redelijke ruil. Gebruik op een server een optiebestand zoals in paragraaf 6.8.

8. Best practices

• Gebruik altijd --single-transaction op een live InnoDB-site. Zonder die vlag vergrendel je de database tegen je eigen bezoekers zolang de backup duurt.
• Zet --routines --events erbij, tenzij je hebt gecontroleerd dat de database geen van beide heeft. Ze gaan niet standaard mee en hun afwezigheid is stil.
• Zet --hex-blob erbij als een kolom binaire gegevens bevat, en verhoog --max-allowed-packet bij zowel het dumpen als het terugzetten als rijen groot zijn.
• Zet de definers op een rij voordat je een database-account verwijdert. Een view of routine die naar een ontbrekend account blijft wijzen, breekt vanaf dat moment elke dump van die database.
• Begin elk backupscript met set -euo pipefail, en controleer daarna zowel de exitcode als de bestandsomvang. Een backupscript dat niet hardop kan mislukken is erger dan geen script.
• Schrijf naar een tijdelijke naam en hernoem bij succes, zodat een mislukte draaibeurt nooit een goede backup vervangt.
• Houd inloggegevens van de opdrachtregel - gebruik --defaults-extra-file met een bestand op chmod 600, en geef het als eerste argument mee.
• Gebruik een apart backupaccount met SELECT, SHOW VIEW, TRIGGER, LOCK TABLES, EVENT, PROCESS, geen root.
• Comprimeer in de pipe met gzip of zstd. SQL-tekst comprimeert een paar keer over en je hoeft het grote bestand helemaal niet weg te schrijven.
• Detecteer de programmanaam in scripts, zodat een MariaDB-upgrade die de mysqldump-symlink weghaalt de taak niet stilzwijgend breekt.
• Haal de dump van de server af. Een backup naast de database beschermt je nergens tegen behalve je eigen fouten, en het is een bestand dat een aanvaller dolgraag vindt.
• Zet hem ergens terug, volgens een schema. Een ongeteste dump is een gok. Terugzetten in een wegwerpdatabase kost tien minuten en is het enige dat bewijst dat de backup werkt.
• Onthoud wat er niet in zit: gebruikers en rechten wonen in de systeemdatabase mysql, niet in de database van je site, en ze zitten niet in een dump van een enkele database.
• Lees de documentatie met man mysqldump, of mysqldump --help voor de vlaggen plus een volledige lijst van elke standaardwaarde.

10. Samenvatting

mysqldump ziet eruit als een gereedschap van een regel en gedraagt zich ook zo, maar bijna alles wat er misgaat met databasebackups gaat mis in de ruimte eromheen: de shell, de pipe, het schema en de terugzetting die niemand heeft geprobeerd.

• Het maakt een logische backup: platte SQL-tekst die je database overal herbouwt, op elke versie, leesbaar en bewerkbaar. Die overdraagbaarheid is waarom het na dertig jaar nog het standaardgereedschap is.
• Het schrijft naar standaarduitvoer. De shell maakt het bestand, en daarom werken omleiding, pipes en compressie zo vanzelfsprekend - en daarom laat een mislukte dump toch een bestand achter.
• Er is geen terugzetcommando. Je voert de dump terug met mysql < bestand.sql, in een database die al moet bestaan.
• --single-transaction is de vlag die op een live site telt: een InnoDB-momentopname in plaats van een tabellock, zodat de backup de site niet meesleurt.
• Standaarden doen het meeste werk via --opt, maar --routines en --events horen daar niet bij, en hun afwezigheid is stil.
• Snoei de dump bij met --where, --ignore-table, --no-data en het tweeslagpatroon dat de structuur van een sessietabel houdt zonder de rijen.
• Objecten onthouden wie ze heeft gemaakt. Een DEFINER die naar een niet meer bestaand account wijst, laat het terugzetten stil slagen en faalt zodra het object wordt gebruikt - en laat de brondatabase helemaal niet meer dumpen.
• De exitcode is eerlijk maar de pipeline niet. Zonder set -o pipefail meldt een volledig mislukte backup succes. Controleer de status, controleer de omvang, en hernoem pas op zijn plek bij succes.
• Op MariaDB heet het programma mariadb-dump, de mysqldump-symlink verdween in 11.4, en dumps beginnen met een sandboxregel die je tegen een vijandig dumpbestand beschermt.
• Weet waar het ophoudt: xtrabackup of mariabackup voor grote databases, MySQL Shell voor parallelle logische dumps, mysqlbinlog voor herstel tot op de seconde, snapshots om een hele server terug te draaien.
• Bij twijfel: typ man mysqldump.

Dit is het overzicht dat je wilt bewaren:

mysqldump -u U -p DB > db.sql            dump one database to a file
mysql -u U -p DB < db.sql                restore it (database must exist)
mysqldump --single-transaction ...       consistent dump without locking (InnoDB)
mysqldump ... | gzip > db.sql.gz         compress in the pipe
gunzip < db.sql.gz | mysql -u U -p DB    restore a compressed dump
mysqldump -u U -p DB tbl1 tbl2           only these tables
mysqldump -u U -p --databases DB1 DB2    several databases, with CREATE DATABASE
mysqldump -u U -p --all-databases        the whole server
mysqldump --no-data DB > schema.sql      structure only (-d)
mysqldump --no-create-info DB > data.sql rows only (-t)
mysqldump --where="state=1" DB tbl       only matching rows (-w)
mysqldump --ignore-table=DB.tbl DB       skip a table (needs DB.tbl)
mysqldump --routines --events DB         include procedures and events
mysqldump --hex-blob DB                  safe binary columns
mysqldump --compact --no-data DB         readable schema, for diffing only
mysqldump --skip-column-statistics ...   8.0 client against a 5.7 server
mysqldump --set-gtid-purged=OFF ...      backup on a GTID server
mysqldump --defaults-extra-file=f.cnf    credentials from a file (must be first)
mysqldump --max-allowed-packet=512M ...  tables holding large TEXT or BLOB values
docker compose exec -T db mysqldump ...  dump from a container (-T for restores)
docker exec -i CONTAINER mysql db < f    restore into a plain docker container

set -o pipefail                          or a failed dump reports success
exit 0 ok | 2 connect or definer | 3 truncated | 6 no such table

Een databasebackup is de goedkoopste verzekering die een website heeft, en hij wordt bijna altijd een keer ingericht en daarna nooit meer bekeken. Het ongemakkelijke is dat een werkende backuproutine en een kapotte backuproutine er van buiten precies hetzelfde uitzien, tot op de dag dat je er een nodig hebt. Wil je de database achter je site laten backuppen, testen en terugzetbaar houden door iemand die de terugzetting al eens heeft gedaan, dan is dat precies het soort stille werk waar ik graag bij help.