Forwarded to devs Plesk migrator don't migrate backup settings

[Pascal_Netenvie]

TITLE:

Plesk migrator don't migrate backup settings​

​

PRODUCT, VERSION, OPERATING SYSTEM, ARCHITECTURE:

Plesk 17.x + Debian 8/9​

​

PROBLEM DESCRIPTION:

Hi,​

Plesk migrator is great except it don't migrate backup settings.​

It's just 4 or 5 parameters to add to migration.​

When we migrate 50 websites in a row it's lot of time losed.​

Please add it to migrator.​

​

STEPS TO REPRODUCE:

Migrate a website with migrator.​

​

ACTUAL RESULT:

No backup settings migrated.​

​

EXPECTED RESULT:

Backup settings migrated and backup scheduled.​

​

ANY ADDITIONAL INFORMATION:

​

YOUR EXPECTATIONS FROM PLESK SERVICE TEAM:

Help with sorting out​

 

[IgorG]

From developers:

We consider the bug as a feature request (as it is complex to implement - especially cover all source/destination Plesk versions).

I have not found any related UserVoice request. So, please submit it and we will implement it if it becomes popular enough.

 

[Pascal_Netenvie]

Ok so where is this UserVoice ?

 

[IgorG]

Ok so where is this UserVoice ?

Feature Suggestions: Top (1370 ideas) – Your Ideas for Plesk

 

[Pascal_Netenvie]

Ok, done.
Thanks.

 

[Pascal_Netenvie]

Any news about this ??

 

[websavers]

Could really use it. The direct link to the UserVoice is here: Make Plesk Migrator also migrate backup settings
@IgorG know of any way to export/import the settings via Plesk DB queries or something like that? (ie: server-wide)

 

[websavers]

You can export these tables with phpMyAdmin. Specify Data only and to use REPLACE:

• BackupsSettings
• BackupsScheduled
• BackupExcludeFiles

Then import them on the destination server. Then run this to rsync existing backup files over:

rsync -av /var/lib/psa/dumps/ root@NEW_SERVER_IP:/var/lib/psa/dumps

This is confirmed working on servers that only have one customer (ie: web admin licenses) and for which backups are configured only to the local server. Will do more testing to find out if it works with external backup storage connections like Dropbox.

---

When it comes to multiple customer servers, from what I can gather the following fields connect each backup config to the correct client or subscription ID (whether customer or reseller) from the 'clients' table:

• Table: BackupsSettings -- Field: id
• Table BackupsScheduled -- Field: obj_id

After the export from the source server, we'd need to find some way to obtain the new client ID from the destination server. We'd then edit the export dump to replace the old ID with the new one, before then importing it on the destination server.

I'm guessing the client guid should remain consistent, so I suppose we could run this on the source:

SELECT clients.guid, BackupsScheduled.id FROM BackupsScheduled
LEFT JOIN clients
ON BackupsScheduled.obj_id=clients.id
WHERE clients.id != 1

And this on the destination

SELECT guid, id FROM clients WHERE clients.id != 1
AND guid IN (GUID1, GUID2, GUID3)

(Where each of the GUID values are the results from the query on the source server)

Then manually update the IDs in BackupsSettings and BackupsScheduled to match the new ID values.

Bit of a pain, and I'm not sure if this'll work for Cloud backup options like Dropbox or OneDrive.

 

[Pascal_Netenvie]

Hi Websavers,
Thanks for this.
I will test that on next migration !

 

[websavers]

The above exports and imports do *not* work to migrate cloud storage connections. Presumably those tokens are stored elsewhere in the DB or in a file somewhere.

If you're migrating a shared server you can use these sql queries to obtain the old and new IDs for domains (where the above queries are for client-level backups), but you'll need to manually update them in your SQL dump from the source server before you import it into the target. Also keep in mind that this will only ensure continuity of backups for those with backups configured to store locally on the server and not using cloud storage.

On the SOURCE server, run `plesk db` then paste in this SQL and run it to get your list of domain IDs with backups configured:

SELECT DISTINCT BackupsSettings.id, domains.name
FROM BackupsSettings
LEFT JOIN domains ON BackupsSettings.id = domains.id
WHERE domains.name IS NOT NULL
ORDER BY domains.name;

Then on the DESTINATION server do the same with this SQL to get the new domain IDs. Make sure to enter your actual list of domains from the output of the above query, in place of domain1.com, etc:

SELECT * FROM clients WHERE name IN('domain1.com','domain2.net','domain3.org',[...]) ORDER BY name;

Now you'll need to edit your SQL dump replacing the domain IDs with their new values.

Still a pretty big PITA that Plesk should be doing for us as part of the migration.

 

[websavers]

As a reminder, for anyone here interested, you should also vote on the uservoice: Make Plesk Migrator also migrate backup settings

That said, IMO this is more of a bug than a feature request because Backup is a built-in and essential part of Plesk. Furthermore the one part that isn't built in (cloud backup destinations) are a paid add-on. If Plesk wants people to continue paying for that functionality, then shouldn't it be reliable across migrations? Doesn't excluding backup configurations during a migration simply serve to drive people away from using Plesk backup and towards alternate solutions, and therefore away from the possibilty of those customers paying more for Cloud Backup options?

I'm actually still surprised that migration of backup settings (a core Plesk feature) was somehow less important than migration of random extension settings, and yet extension settings *are* migrated.

 

[websavers]

3 years later and we've reached the CentOS 7 EOL (when last it was CentOS 6) and we still have to tell customers to reconfigure their backups after a migration

 

[Peter Debik]

Have you seen and tried the free Plesk centos2alma tool?

GitHub - plesk/centos2alma: CentOS 7 to AlmaLinux 8 conversion tool

CentOS 7 to AlmaLinux 8 conversion tool. Contribute to plesk/centos2alma development by creating an account on GitHub.

github.com

 

[websavers]

Have you seen and tried the free Plesk centos2alma tool?

GitHub - plesk/centos2alma: CentOS 7 to AlmaLinux 8 conversion tool

CentOS 7 to AlmaLinux 8 conversion tool. Contribute to plesk/centos2alma development by creating an account on GitHub.

github.com

Indeed! Wish we could use it, but we run Plesk inside OpenVZ containers and they're not supported by this.

We also converted a couple barebones CentOS 7 KVM VPS to AlmaLinux 8 using ELevate and there was fairly significant downtime for a server that was stock CentOS 7 + OpenVPN only. I imagine that would be even longer on a bigger box with Plesk installed. The migration process may require more tech time, but at least we can better limit downtime with it.

 

[Peter Debik]

I see, yes, it takes a while to convert a server. I tried it on an 12-core machine with 1000+ domains and it took almost an hour. But did you succeed - regardless that it took a while?

 

[Pascal_Netenvie]

Almost 5 years later and backup settings are still not migrated ...

 

[websavers]

I see, yes, it takes a while to convert a server. I tried it on an 12-core machine with 1000+ domains and it took almost an hour. But did you succeed - regardless that it took a while?

It did work! CentOS 7 -> AlmaLinux 8 was smooth. I then took it to AlmaLinux 9, and there were odd charset issues showing in initram initialization and it needed a manual reboot after it finished there, but OS seems to work OK other than it refusing to accept root logins despite PermitRootLogin being enabled.

Granted this was ELevate directly as there was no Plesk on that particular server.

 

[websavers]

Any tips as to where we might find the configurations for cloud backups? I'd like to see if we can find a way to manually move those over.

 

[websavers]

We've written a guide and PHP script to show how to export the data, then automatically update the exported data with the new domain and client IDs, then import the data into the new server. It can be found here: GitHub - websavers/Plesk-Migrate-Backup-Settings: Run this on old and new server to migrate backup settings

Turns out the tokens and configuration data for cloud backups are stored in the DB in a spot where Plesk Migration Manager *does* copy those for us.

Unfortunately it seems the tokens for at least some cloud services are invalidated after the migration - I'm betting due to a fingerprinting of the server being part of the token creation for security purposes. That means clients need to reconfigure their connection to cloud services, but at least all their settings remain in place and Plesk should notify them of issues backing up.