Migration to konsoleH from another hoster
If you want to move your website and database from another hoster to konsoleH, the migration is essentially a restore – the backup file just doesn't come from konsoleH itself, but from your previous hoster.
Typical workflow:
- At your old hoster: Export your database as an SQL file (using the phpMyAdmin available there or via SSH with
mysqldump). - In konsoleH: Under
MariaDB/MySQLorPostgreSQL, create a new, empty database. Note down the new connection details. - Import the SQL file into the new database via phpMyAdmin/phpPgAdmin (see above).
- Adjust your application: In your CMS configuration file (e.g.
wp-config.php,configuration.php), enter the new connection details – in particular the new hostname, the database name, and the username. - Thoroughly test your website before pointing your DNS record to konsoleH.
Tip: Plan for at least a short maintenance window during a migration, in which no new data can be created on the old website. Otherwise, orders, comments, or registrations that arrive on the old system after your export will be lost.
Automatic backups by konsoleH
konsoleH automatically creates backups of your databases and keeps versions of the last 14 days. This means you do not have to take care of regular backups yourself in order to be able to restore an older state in an emergency.
You will find the available backups in konsoleH under MariaDB/MySQL or PostgreSQL by clicking on the Backups icon for the relevant database. From there, you can select an older version and restore it.
Important: automatic backups are not a catch-all safety net
Do not rely on the automatic backup alone when making risky changes (CMS updates, data migrations, larger structural changes). Create an additional manual backup directly before the change – this way, in case of an error, you have the exact state you need at hand and don't have to hope that the timing of the automatic backup was favourable.
Creating your own backup
For a manual backup, you have two options. Which one is suitable for you depends on the size of your database and on your hosting plan.
Option 1: Using phpMyAdmin / phpPgAdmin (GUI)
This is the easiest way and works without issues for most databases up to around 50 MB.
- In konsoleH, open your database under
MariaDB/MySQL(orPostgreSQL) and launch phpMyAdmin or phpPgAdmin. - Select the database you want to back up in the left column.
- Click on the
Exporttab. - Choose the
SQLformat and selectQuickfor small databases orCustomfor more control. - Download the resulting
.sqlfile to your computer.
Tip for larger databases: Under "Custom", select the option
gzip compressed. This makes the file much smaller – which helps with downloading and especially with importing later, since phpMyAdmin and phpPgAdmin can also import compressed files directly.
Option 2: Via SSH (only with plans that include SSH access)
If your hosting plan includes SSH access, the direct command-line route is more robust – especially for large databases, where phpMyAdmin can fail due to time limits.
For MariaDB/MySQL:
mysqldump --host=YOUR_HOSTNAME --user=YOUR_USERNAME --password YOUR_DATABASE_NAME > backup.sqlFor PostgreSQL:
pg_dump --host=YOUR_HOSTNAME --username=YOUR_USERNAME YOUR_DATABASE_NAME > backup.sqlBoth commands create a SQL file on your computer that you can store safely or reuse.
Restoring from your own backup
To restore from your own backup, you essentially follow the same workflow in reverse.
Using phpMyAdmin / phpPgAdmin
- Open phpMyAdmin or phpPgAdmin for your database.
- Select the target database in the left column.
- Click on the
Importtab. - Select your
.sqlfile (.sql.gzis also supported) and start the import.
Caution with existing data: When importing, existing tables with the same name are either overwritten or cause errors – depending on how the backup was created. To be on the safe side, create an empty database before the import and import the backup there.
Common import problems
- File too large: phpMyAdmin only accepts imports up to a certain size (max. 2048 MB). For larger files, either use Option 2 via SSH or split the SQL file.
- Character set issues (umlauts appear as
???): Make sure the same character set (usuallyutf8mb4) is used for the export as for the target database.