A completed dump is not a completed recovery test
This procedure covers logical backups using MariaDB tools. It is not a raw data-directory migration and does not assume that an old MySQL dump can be restored into any MariaDB release. Match the client/server versions, character sets, schema and game build used in your environment.

1. Discover what must remain consistent
List the schemas used by authentication, characters, items, guilds and other branch-specific systems. Do not assume account/player/common/log are the exact names in every pack. Record the database version and table engines. From your normal authenticated database session, this read-only query lists non-system tables:
SELECT TABLE_SCHEMA, TABLE_NAME, ENGINE
FROM information_schema.TABLES
WHERE TABLE_TYPE = 'BASE TABLE'
  AND TABLE_SCHEMA NOT IN
      ('information_schema','performance_schema','mysql','sys')
ORDER BY TABLE_SCHEMA, TABLE_NAME;

Keep the inventory private. Identify MyISAM/MEMORY tables as well as InnoDB before choosing a backup method.

2. Choose the consistency method
For InnoDB-only data, mariadb-dump --single-transaction can capture a consistent snapshot without blocking normal writes. It does not provide that guarantee for changing MyISAM/MEMORY tables. Avoid schema-changing operations such as ALTER, DROP, RENAME or TRUNCATE during the dump. If the installation mixes engines, use a planned write-stop/locking or supported physical-backup procedure appropriate to the database version. Do not call a mixed-engine hot dump consistent without proving it.

3. Example logical dump for a confirmed InnoDB case
The following is a POSIX-shell example. Replace account/player/common with all actual required schemas. Use a restricted backup account with the privileges needed for the selected objects, a private backup directory and a unique output filename. Do not put a password directly on the command line:
umask 077
mariadb-dump --host=127.0.0.1 --user=backup_operator --password \
  --single-transaction --quick --routines --events --triggers \
  --databases account player common > metin2-before-update.sql
backup_status=$?
printf 'dump exit status: %s\n' "$backup_status"

Accept the backup only if the command succeeded; retain errors and investigate any incomplete file. Exporting routines/events may need additional privileges. Protect and encrypt copies stored elsewhere, with recovery keys kept separately and access tested. Never place this dump under your website's public directory.

4. Restore to a disposable isolated instance
Use an empty test database instance, not the production host. Check its identity/version before import. Disable scheduled event execution and isolate outbound connectivity in the test instance so restored jobs cannot affect live services. The dump above contains database-selection statements: specifying another default database is not sufficient to redirect everything safely.

Restore with the supported mariadb client into that isolated instance, using an account authorised only there. Follow the official restore guide. Do not use --force to turn ignored import errors into a successful test. Record the exit status and errors.

5. Verify the game state, not just table counts
Compare expected schema objects and representative record counts. Connect only a staging game build to the restored database. Check test-account login, a character's inventory/currency, a relevant quest state and persistence after restart. Record backup time, restore duration, database/build revisions and the acceptable recovery point. Keep sensitive player data access restricted throughout the drill.

Scope and reference
The consistency limitations and options were checked in the official mariadb-dump documentation. No real player database was dumped or restored to write this tutorial. Post your engine/version combination and a redacted restore error if you need help; never attach a player database.