Backup/Restore Questions for Migration

[davidc]

I don't do this everyday - I haven't even done it once!

I am moving from a Centos 7 VPS within the same datacenter to a Debian 11 VPS. The new server has a DA Lite (10 account & 50 domain) license.

Question:

Does the receiving server have to be organized (admin/reseller/users) identically to the source server?

The reason I'm asking is because over the years, I've learned a little about organization. So, I am trying to "group" the domains a bit differently this time. I only have 2 user accounts (admin and one reseller) on both the source and the receiving. However, whereas the source had 14 accounts (mostly 1 domain) under the reseller, this time I want to divide up the domains into the admin and reseller accounts.

I made a "user" backup and noticed that it landed in /home/account, which had 1 domain, but now will have 3 or 8 domains.

If I restore this backup and then restore several other backups, is it going to be a jumble?

I will appreciate the replies.

David

 

[Richard G]

Does the receiving server have to be organized (admin/reseller/users) identically to the source server?

Not particularly, but it makes restoring way easier, otherwise you might have to rename backups before restoring for example.

In that case it's better IMHO to first group them like you want to have them on the current VPS and then transfer them to the new one so everything is the same.

If I restore this backup and then restore several other backups, is it going to be a jumble?

That all depends on how it's done. If you make a mistake with selecting then a restore can easily overwrite a previous backup. Which is why it's best to use the admin backup/restore on server movement. And also why it's better to have things how you want them, before starting to transfer.

Especially because you haven't done it before!

 

[davidc]

Writing this post as a source of info for others who may follow ...

In that case it's better IMHO to first group them like you want to have them on the current VPS and then transfer them to the new one so everything is the same.

Using caution, I decided to stand fast to the "future organization", rather than re-organize the old, followed by re-organize the new.

That all depends on how it's done. If you make a mistake with selecting then a restore can easily overwrite a previous backup. Which is why it's best to use the admin backup/restore on server movement. And also why it's better to have things how you want them, before starting to transfer.

Especially because you haven't done it before!p

So, I decided to use the "User level" site backup, rename the files and copy them over to the new VPS. (There are only 10 domains)

I found:

1. While there were the folders admin_backups & user_backups in /home/<username>/domains folder, Restore backup did not find the uploaded backup in /domains or user_backups. The solution was to make a User level backup, which created the /backups folder with a small backup file.

2. Naming the backups, for clarity in the restore, caused a problem. At first, I edited the file name to include the username to help keep them straight. Restore backups did not show them in the drop-down selection. The solution was to name them backup-Jul-09-2024-<username>.tar.zst

3. At this point, I've discovered that cronjobs were not copied. (It is plainly NOT present in the documentation) This is easy enough to transfer.

What else is not being transferred? (rhetorical question)

 

[Richard G]

Writing this post as a source of info for others who may follow ...

Others might better use the more wise procedure I suggested, rather then re-organizing afterwards.

1. While there were the folders admin_backups & user_backups in /home/<username>/domains folder, Restore backup did not find the uploaded backup in /domains or user_backups. The solution was to make a User level backup, which created the /backups folder with a small backup file.

You might have found this due to the way you did things. For the restore backup to find the uploaded backup, it totally depends on exactly which backup you created and from where.
Be aware that admin is also a user and a reseller.

If you create a real user backup then you need to restore it from the /home/user/backups folder. If that folder is not present, then you have to create it. If you had done like I suggested, using admin backup/transfer, you woulnd't have encountered this issue either.

2. Naming the backups, for clarity in the restore, caused a problem.

I had warned you for that.
For all different backups, the naming is also different and needs to be correct for the restore to be able to see them. Makes life harder. Which is also why organising things before and using admin/backup transfer can prevent odd issues.
Also restoring from the correct place with the same method as the backup can prevent issues.

3. At this point, I've discovered that cronjobs were not copied. (It is plainly NOT present in the documentation) This is easy enough to transfer.

That might be a bug then. Because normally they are copied. You can check the backup file and see if there is a crontab.conf file in there.
You might want to check that and if no cronjob.conf is made in the backups you made, I would suggest reporting this to Directadmin in a ticket.

 

[adam12]

Richard already went into super deep detail, per usual, so I only really have some anecdata to add.

I just finished a lot of these migrations (to Debian 12 but I digress), and they all went off without a hitch. But my original objective was essentially a 1-1 migration, where every last detail outside of the distribution and distro packages was exactly the same. Same options.conf, same php_extensions.conf, same directadmin.conf values, same same same.

So definitely either organize before, or organize after, but IMHO, I'd leave everything the same during the migration.