Export database with phpMyAdmin

With phpMyAdmin, you can export a database of your CURIAWEB web hosting as a file. Such an export is useful, for example, before making changes to a live database, manually migrating a website, or creating an additional backup of the database.

For typical website databases, this is suitable for SQL format. The exported SQL file contains the database structure and – depending on the selected settings – the saved data and can later be imported back into a database.

In this guide, we will show you step by step how to select the correct database in phpMyAdmin, create an export, and then check whether the backup file was actually downloaded.

Important: A phpMyAdmin export backs up the database, but not automatically your website files, emails, or the entire hosting account. For a complete manual website backup, database-driven websites typically require both the website files and the database.

When is a database export useful? #

An export is particularly useful if you want to back up a database before modifying it.

Typical use cases are:

• before manual changes with phpMyAdmin
• before major changes to a website
• prior to manual database cleanup
• during a website migration
• before importing other data
• for an additional local backup of the database

Basic rule: With a production database, the rule is: export first, then modify.

What does an SQL export contain? #

A SQL file contains statements that can be used to restore the structure and data of a database or to import them into another database.

Depending on the export options, this may include, for example:

• Table structures
• Table contents
• Indices
• additional SQL statements required for the exported database objects

For example, a typical export file might be named:

kunde_wordpress.sql

You do not need to manually edit the SQL file for a regular backup.

1. Log in to cPanel #

Log in to your CURIAWEB cPanel.

Then open:

Databases → phpMyAdmin

phpMyAdmin is being opened for your hosting account.

You can find a general introduction to the user interface under Use phpMyAdmin in cPanel.

2. Select correct database #

In the left navigation of phpMyAdmin, select the database you want to export.

Check the full name carefully.

For example, a database name can look like this:

WordPress customer

If there are multiple websites in your hosting account, a corresponding number of databases may be displayed.

Attention: Do not rely on guesswork when dealing with multiple similarly named databases. First, check which database is actually being used by the website in question.

How do I find the database of my WordPress website? #

In WordPress, the used database name is usually in the file:

wp-config.php

on file.

The relevant entry is:

DB_NAME

The value stored there should correspond to the database name you select in phpMyAdmin.

Safety: wp-config.php contains sensitive information in addition to the database name. Do not publish its complete contents.

3. Check if the correct database is open #

After selecting the database, phpMyAdmin displays its tables.

Check the database name again and verify whether the existing tables match the expected application.

For example, in WordPress, tables such as:

wp_posts
wp_options
wp_users
wp_postmeta

to exist.

However, the table prefix is not required wp_ loud. A WordPress installation can use a different prefix.

4. Open export function #

When the correct database is selected, open the section at the top of phpMyAdmin:

Export

phpMyAdmin will then show you the available export methods and the export format.

5. Choose Fast or Custom #

phpMyAdmin typically offers two export methods:

Fast and Adapted.

Which variant makes sense depends on what you plan to do with the export.

Fast #

The method Fast uses the intended default options and is often sufficient for an uncomplicated export of a normal database.

If you simply want to export a complete database and have no special requirements, this method is a good starting point.

Adapted #

With Adapted you get access to additional export options.

You can use this, for example, to specify more precisely which tables are exported or how the SQL file should be generated.

Practical Tip: Do not automatically use the customized export just because more options are available there. For a normal backup, a simple full export is often the better and less error-prone choice.

6. Select SQL as format #

For a normal backup or migration of a MySQL-compatible website database, choose the format:

SQL

SQL is suitable for later importing the database structure and the stored data back into a MySQL-compatible database.

Other export formats can be useful for special tasks, but are usually not the first choice for a classic database backup.

7. Start export #

Check again:

• correct database
• desired export method
• Format SQL

Then start the export.

Your browser should download the generated export file.

8. Actually check download #

Do not assume the export was successful just because you clicked the export button.

Then check in the download folder or in your browser's download display to see if the file is actually there.

For example, a file could be named like this:

kunde_wordpress.sql

Important: A clicked export is not yet a verified backup. Check whether the file was actually downloaded.

9. Check file size #

Additionally, check the size of the downloaded file.

Size alone does not prove that a backup is complete and error-free, but it can make obvious problems visible.

If you receive an unexpectedly tiny file for a large production database, for example, you should verify the export before relying on that backup.

A small SQL file is not automatically faulty #

The size of a database depends heavily on the application and the stored content.

A small website can have a correspondingly small database.

Therefore, do not judge an export solely by its file size.

10. Name the SQL file meaningfully #

For later backups, it can be helpful to add a date to the filename.

For example:

kunde_wordpress_2026-08-28.sql

This makes it easier for you to distinguish between several backup states.

Do not use database passwords or other confidential access credentials in the filename.

11. Keep SQL file safe #

A database backup may contain confidential content.

Depending on the website, this may include, for example:

• User information
• Email addresses
• Order details
• Website settings
• internal application data

be saved.

Therefore, do not treat an SQL backup like a publicly accessible file.

Safety: Do not upload database backups to a publicly accessible website directory. A backup file does not belong unprotected in public_html.

Do not leave backups publicly accessible on the webspace #

When you need to transfer an SQL file to the server for a migration, it should not remain unnecessarily long in a publicly accessible directory.

Remove no longer needed temporary backup files after completing the work.

12. Use custom export #

If you the method Adapted you select, phpMyAdmin provides additional options.

This method is useful, for example, if you only want to export certain tables or have special requirements for the export file.

When performing a full website database backup, you should make sure not to accidentally exclude required tables.

Include all tables on a website #

A web application can have significantly more tables than the obvious core tables.

For example, WordPress plugins can create additional tables.

If you need a complete database backup, you should not exclude such tables just because you do not know their names.

Attention: An export of only the known WordPress core tables is not automatically a complete backup of the entire WordPress database. Plugins may use their own tables.

Export only specific tables #

If you intentionally need only individual tables, you can select them during the customized export.

This can be useful, for example, for a targeted analysis or transfer of individual data.

However, such a partial export should be clearly distinguished from a complete database backup.

Use compressed export #

Depending on the phpMyAdmin configuration, compression options may be offered for customized exports.

Compression can reduce the size of the downloaded backup file, especially for larger databases.

Which options are actually available depends on the server and phpMyAdmin configuration.

SQL file or compressed file? #

Depending on the selected export option, the result can be a normal SQL file or a compressed backup file, for example.

Examples:

database.sql
database.sql.gz
database.sql.zip

Which variant you use depends, among other things, on the database size and the later import procedure.

DROP statements in custom export #

During a customized SQL export, options can be offered that, before creating tables, corresponding DROP- Include instructions in the export file.

Such instructions can initially remove existing objects with the same name during a later restoration.

Attention: Options with DROP you should not activate this thoughtlessly. During a later import, this could cause existing tables to be removed before they are recreated from the backup.

Understanding CREATE TABLE and INSERT #

A typical SQL backup can contain different types of statements.

Simplified:

CREATE TABLE
→ creates a table structure

INSERT
→ inserts stored records

For a complete recovery, normally both the required structure and the data are needed.

Do not „clean up“ the export manually“ #

Do not open a SQL backup file with just any text editor and delete sections in it on suspicion just because they seem unfamiliar to you.

This can make the backup incomplete or unusable during a later import.

Can I open the SQL file? #

An uncompressed SQL file is fundamentally a text file and can be viewed with suitable tools.

However, with large databases, it can be very extensive.

To check a normal backup, it is not necessary to manually read through all SQL statements.

Export before a change with phpMyAdmin #

When planning a manual change to a production database, the following procedure is recommended:

1. Open phpMyAdmin.
2. Choose the right database.
3. Export the database.
4. Check the successful download.
5. Keep the backup safe.
6. Execute the planned change only after that.
7. Test the website immediately after the change.

We explain how you work with tables and data sets under Use phpMyAdmin in cPanel.

Export for website migration #

During a manual migration of a database-driven website, you typically need at least two components:

Website files
+
Database
=
essential components of the website

You can transfer the website files using the cPanel File Manager or FTP, for example.

Export the database using phpMyAdmin and then import it into the database of the new hosting environment.

We explain how to download files via cPanel at Upload, download, and edit files in cPanel.

Create new database at target #

During a manual migration, a new database may first need to be set up at the destination.

You can find the procedure under Create MySQL database in cPanel.

In addition, the application typically requires a database user with the necessary permissions.

We explain this step under Create MySQL user and assign to a database.

Export then import #

You can then import the generated SQL file into a suitable target database.

The complete instructions will follow below Importing a database with phpMyAdmin.

Attention: Always check the selected target database before importing. Depending on its content, an SQL file can modify existing data and tables.

Export is not an automatic move #

When you export a database, it does not automatically transfer the website to another server.

During a manual migration, the website files must be transferred, the database set up or imported at the destination, and the application connected with the new database credentials, among other things.

WordPress after a database migration #

If the database name, database user, password, or database host changes at the new location, the WordPress configuration must be adjusted accordingly.

The relevant values are usually located in:

wp-config.php

These include:

DB_NAME
DB_USER
DB_PASSWORD
DB_HOST

Only change these values according to the actually configured database access credentials.

Export is not the same as a backup of the entire hosting account #

A phpMyAdmin export only includes the selected database or the selected database objects.

It does not save automatically:

• Website files
• Images and uploads in the file system
• Plugins and themes as files
• Email mailboxes
• FTP accounts
• cPanel settings
• the entire hosting account

Therefore, do not refer to a single SQL export as a complete backup of the entire web hosting.

WordPress database export does not back up media files #

WordPress stores information about media in the database, but the actual uploaded image, PDF, or other media files are usually located in the file system.

Therefore, a pure database export is not sufficient to completely restore a WordPress website.

Recreate export after major changes #

An SQL backup is always just a snapshot of the database state at the time of the export.

If the website continues to change after that, the older backup will not contain this new data.

For dynamic websites, for example, new orders, users, comments, or settings can be added.

Important: On an active website, a database backup can quickly become outdated. For a migration, the timing of the final export should therefore be chosen carefully.

Special feature of online shops and highly dynamic websites #

In an online shop or a website with ongoing user activities, data can continue to change during a migration.

If new orders or other records are created after your export, they will not be included in the already exported SQL file.

Migrating such systems therefore requires a coordinated approach so that no relevant data is lost between the export and the switchover.

Export file contains sensitive data #

An SQL backup can be much more sensitive than its filename suggests.

Depending on the application, it can contain personal and business data.

Store and transfer such files with appropriate protection and delete temporary copies that are no longer needed.

Do not send export file via public link #

Do not place an SQL file in a publicly accessible directory and then simply send its URL.

When a database backup needs to be transferred, use a suitable secure transmission channel.

Export is not working #

If no file is downloaded during the export, check first:

• whether the correct database was selected
• whether your browser has blocked a download or saved it in a different location
• whether phpMyAdmin displays an error message
• whether the database or the export is unusually large

Note down any displayed error message completely before changing settings on a whim.

Export large database #

For very large databases, a browser-based export via phpMyAdmin can hit practical or technical limits depending on the environment.

In such cases, it should first be checked how large the database actually is and at what point the export fails.

Do not change PHP limits randomly without knowing the specific cause.

Export successful – is it guaranteed that the backup can be restored with this? #

A successful download is an important first step, but it does not completely prove that the backup can later be restored without issues under all circumstances.

Therefore, a reliable backup strategy also takes into account the restorability of the backups.

Practical Tip: A backup is especially valuable when not only its existence, but also the intended recovery procedure is known.

Do not delete SQL file after export #

If you explicitly created the export as a backup before a change, keep it at least until the change has been successfully completed and the website has been checked.

Otherwise, you might remove the very fallback level that you created before the change.

Keep multiple anchor stations apart #

If you create multiple exports, use unique file names.

For example:

customer_wordpress_before-update_2026-08-28.sql
customer_wordpress_before-migration_2026-08-28.sql

This makes it easier for you to understand later at what time and for what purpose a backup was created.

Recommended procedure for a normal database export #

1. Log in to cPanel.
2. Open Databases → phpMyAdmin.
3. Select the correct database on the left.
4. Check database name and tables.
5. Open Export.
6. Select for a normal full export Fast.
7. Choose SQL as a format.
8. Start the export.
9. Check if the file has been downloaded.
10. Check filename and file size plausibility.
11. Keep the file safe.

Recommended procedure before a database change #

1. Identify the correct production database.
2. Generate a current SQL export.
3. Check the download.
4. Keep the unmodified export file.
5. Execute the planned change.
6. Test the website immediately afterwards.
7. Keep the backup until you are sure the change is working correctly.

When should you contact support? #

If an export does not work or if you are unsure which database or tables need to be backed up on a production database, you should not make changes on a whim.

For an analysis, the following information is particularly helpful:

• affected domain or application
• full database name
• approximate database size, if known
• selected export method
• selected export format
• exact error message
• whether a file is downloaded at all
• whether the export is needed for a backup, migration, or other task

Do not transmit database passwords and do not make SQL backups with sensitive content publicly available.

Summary #

You export a database in the CURIAWEB cPanel via Databases → phpMyAdmin. First, select the correct database and then open the area Export.

For a normal full export, the method Fast with the format SQL often sufficient. If you need specific tables or additional export options, you can instead Adapted use.

Check after the export whether the backup file was actually downloaded and keep it secure. SQL files can contain sensitive website and user data and do not belong in publicly accessible directories.

Please also note that a phpMyAdmin export only backs up the database. For a complete manual backup or migration of a database-driven website, you additionally need the corresponding website files.

Therefore, before making manual changes to a production database: Check the correct database, export, check the download, and only then make changes.