Problem with Restore

[dlong500]

It's entirely possible that I'm overlooking something, but I'm having a an issue with restoring a reseller account and all user accounts under that reseller.

I should mention that I am using a "pre-release" build 1.331 of DirectAdmin but I don't believe any of the changes relate to DNS or the backup/restore system.

The main problem is regarding DNS zone data. I was expecting the DNS zones to essentially be replicated exactly as they were on the old machine (with the exception of course of an IP change). However, after the restore process the DNS zones had a mix of the old records plus most of the default records that you would get if you were adding an account for the first time. This is problematic as I had to go and manually correct all the zones. In some cases even things like the SPF TXT record was overwritten with the default SPF record. Can anyone shed any light on this?

Also, there was some manual correction needed with the IP settings, as I had an IP that was shared among many users but when restored DirectAdmin marked it as owned by a particular user.

I'd go through the process again to see if the same thing would happen but I don't have a lot of time and I'm not sure how I could test the restore on another server without having another DA license.

 

[DirectAdmin Support]

Hello,

Regarding the dns restore, the zones are not simply copies and an IP swap done... this would be nice if it would work, but that's not the case. DA still needs to respect the new record data default values (templates/dns_*.conf) so it needs to merge the old values and new values, and then do the ipswap on the old values. For TXT/spf records, the old and new TXT records are merged into 1 pile. Any spf records are removed (defined by having "v=spf1" in the value). Then DA adds the default spf from dns_txt.conf. (assuming I'm reading the code and comments correctly). The bottom line, is that there are going to be multiple different cases and scenarios for dns record restores. This was found to be a good balance between allowing customization, and enforcing new values that admins want to use... and things simply working. But it can't handle every single case unfortunately, DA isn't able to read minds, so we're forced to tweak things that DA misses for those cases.

Regarding the IP... did you set the new IP as shared before restoring any users to it? DA doesn't know that it was shared on the old box. It only knows the state of the current IP on the new box. So just like adding users to IPs in DA normally, the same goes for restores. If you add a User to a free IP, it becomes owned. If you're going to want many users on that IP, you must set it as "shared" ahead of time.

John

 

[dlong500]

OK, that makes sense regarding the DNS issues.

For someone like me who is wanting basically an exact replica of the original DNS zones, would you see a problem with the following procedure?:

1) Restore backups onto new server
2) Copy original DNS zone files to new server, overwriting newly created files
3) Search/replace any relevant IP info in files.
4) Change the TTL using this procedure so that the zone files will get new serial numbers.

Regarding the IP, that is exactly what happened. I had no IPs assigned or users created before restoring the backup, so I guess it just assigned the IP to the first user created from the backup. I just manually updated the relevant /usr/local/directadmin/data/admin/ips file by changing 'owned' to 'shared' and replacing the username with the user count. Is that OK to manually change that file like that?

 

[nobaloney]

I think you misunderstand you work in your #4 a bit.

All that will do is change the TTL. You should do it on your old server before you do the backup/restore.

Whenever you do any manual editing to your DNS you must change the serial number yourself; you can do it this way:

echo "action=rewrite&value=named" >> /usr/local/directadmin/data/task.queue

Do this manually on the new server after you've made the manual changes to DNS.

Jeff

 

[dlong500]

I think you misunderstand you work in your #4 a bit.

All that will do is change the TTL. You should do it on your old server before you do the backup/restore.

Actually the reason I was doing the TTL change was because I thought there might need to be an actual change in the zone data for the DirectAdmin rewrite to actually update the serial. Since some of my domains did not contain any changes, not even a different IP, I wanted to make sure something in the zone changed.

The TTL change will work to update the serials but it just includes a couple of unnecessary steps since I now know that the rewrite command will work without any zone data changed.

I hope you understand what I'm trying to say.