Planned for 11.32 [case 50724] Overwrite existing MySQL database on backup restore

[MironJ]

Hi,

In version 11.30 mysql databases are not restored from backup with all other files if under cpanel account already exist database with the same name.
In version 11.28 and all other before MySQL databases was restored altogether with all files.

Currently we can check checkbox "Restore MySQL DBs" before backup restore, but restored databases are only databases deleted from cpanel account before restore, existing databases are skipped and only files are restored.
That partial restore results in broken website, especially when we need restore some CMS like Joomla or Wordpress.

Please add another option "Overwrite existing MySQL DBs" so we can easily restore complete account from backup archive.
Currently we can restore only account files but MySQL databases need manually restore via SSH.


Regards,
Miron J.

[cPanelDavidG]

You want this to work, even if you're overwriting another user's database? In an environment where user prefixing is disabled, a user creates a database called "sales_db" - then you go to import a user who was in an environment where prefixing was enabled, and their username was "sales" and they had a database named "sales_db."

So even though sales_db doesn't belong to user sales, you still want the sales_db (belonging to user: sales) to overwrite the existing content of sales_db (not accessible to user sales)?

There seems like there should be a much more refined way of doing this. Any suggestions?

[MironJ]

I have not disabled user prefixing, so I will not overwrite any wrong database when i'm restoring an account from daily/weekly server backup, just databases under user account that is restored.
Maybe if you can add another option "Overwrite existing MySQL DBs", and some warning info message right at database restore point if "Overwrite existing MySQL DBs" is enabled, so instead of skipping database restore, show popup message box and ask admin to approve (this/all) or skip database restore.

[cPanelDavidG]

Okay, let's see what other folks think before we go out and implement this.

In the meantime, if you want, you can try reporting this as a bug. This is one of those few times where it's hard to judge if this would be considered a bug (since databases are not being restored) or a feature (now allowing databases to be overwritten in a situation where the database could be owned by another user).

If you do get a case number, post it here so I can update this thread when that case is resolved.

[MironJ]

I think that this issue is covered with cPanel bugreport ID# 1513325 , please check.

[cPanelDavidG]

Thanks for the head's up. Just making sure all avenues on this were being pursued .

[Kent Brockman]

You want this to work, even if you're overwriting another user's database? In an environment where user prefixing is disabled, a user creates a database called "sales_db" - then you go to import a user who was in an environment where prefixing was enabled, and their username was "sales" and they had a database named "sales_db."

So even though sales_db doesn't belong to user sales, you still want the sales_db (belonging to user: sales) to overwrite the existing content of sales_db (not accessible to user sales)?

There seems like there should be a much more refined way of doing this. Any suggestions?

Well, the script must be enough intuitive to check these kind of posibilities before beginning the copy of the first file.
- If there is any user with the same name of those you want to import/restore, it has to offer the option to rename or abort.
- If there is any database with the same name of those you want to import/restore, it has to offer the option to rename or abort if it belongs to another user (when importing/restoring), and the option to overwrite/rename/abort if it belongs to the same user (when restoring, only?).

In both cases, the screen should show the warnings about what may happen if you rename a user or database, to avoid the sysadmin from commiting a big mistake, because in the majority of cases, this task will probably be executed on demand by a host admin in response to a support ticket requesting help on import/restore some account. I don't want to mess around customers' databases! :P

[aegis]

I've also just come across this change in behaviour which had me puzzled for a couple of days.

I would think it would be fair to keep the pre-11.30 behaviour IF database prefixes are still enabled and an override option if not.

[xanubi]

I've also just come across this change in behaviour which had me puzzled for a couple of days.

I would think it would be fair to keep the pre-11.30 behaviour IF database prefixes are still enabled and an override option if not.

I agree with this. This bug/problem, is very annoying and is not easy when we've thousands of clients and many requests for restoring a mysql database backup (override).

[cPanelDavidG]

We current anticipate accommodating this in version 11.32.

[sneader]

Stumbled upon this thread today, looking for something else. This is scary stuff! When I do a "restore" in WHM, I darn well expect the users database(s) to be rolled back and restored to their backup state, when the checkbox "Restore MySQL DBs" is checked.

Glad it is being addressed.

- Scott

[activa]

SAME isseu here ...

we need to return this option to restore daatabases from restore backup .

1+ VOTED

[Robert_]

Same issue for me as well.

[activa]

Today , when i want to transfer accounts from server A to server B i get the same error

(Sorry, a mysql database with the name already exists) Skipping username_database

note the server A is empty and new server !!!!!!!!!!!!

WHM 11.30.3 (build 3)

[jeroman8]

YEPP, SAME ISSUE HERE!
Trying to move accounts between servers.

(Sorry, a mysql database with the name already exists) Skipping xxxx_xxxx