Database backups and migrations

Take a full dump on a schedule

Export the whole database to a .sql file on a schedule (daily for an active server). In HeidiSQL: right-click the database, Export database as SQL, to a dated file. From the command line, the dump tool does the same.

mariadb-dump -u root -p fivem > fivem-2026-06-12.sql

On a pure MariaDB box the dump tool is mariadb-dump. The old mysqldump name still works because MariaDB ships it as a compatibility symlink, but if mysqldump returns command not found, use mariadb-dump instead. They take the same flags.

To make daily real instead of aspirational, run that command on a schedule. On Linux, a cron line that dumps every night at 4am:

0 4 * * * /usr/bin/mariadb-dump -u root -pYOURPASS fivem > /backups/fivem-$(date +\%F).sql

On Windows, create a Task Scheduler task that runs the same mariadb-dump line in a .bat file. If you run txAdmin, its scheduled-tasks feature can fire a backup script on the same cadence as your restarts.

Store backups off the server box

Copy dumps somewhere other than the server machine (another disk, a private bucket). A backup that dies with the server is not a backup.

Migrate schema safely

Before any schema change: take a fresh dump, run the change on a throwaway copy first, and prefer additive changes (ADD COLUMN) over destructive ones. Never run an untested ALTER/DROP against live data.

First build the copy from your latest dump and run the migration there:

mariadb -u root -p -e "CREATE DATABASE fivem_migrate_test;"
mariadb -u root -p fivem_migrate_test < fivem-2026-06-12.sql
mariadb -u root -p fivem_migrate_test -e "ALTER TABLE players ADD COLUMN bank INT NOT NULL DEFAULT 0;"