Jetbackup 5 restore issues
I had to do a disaster recovery restore to a new server this week and there were numerous issues.
No addon domains or subdomains were restored, nor were their associated email accounts restored.
This was the error message in the Jetbackup 5 log:
26/Mar/2024 22:52:06 +0000] [PID 2719633] Restoring domain domain.com (including DNS zone file)
[26/Mar/2024 22:52:07 +0000] [PID 2719633] [ERROR] Failed making API Call to cPanel/WHM (cpapi2). Error: (XID wnh76r) (XID z89xyb) A DNS entry for the domain “subdomain..com.domain.com” already exists. at /usr/local/cpanel/Cpanel/Admin/Modules/Cpanel/subdomain.pm line 176.
I opened a ticket with Jetbackup and they suggested this may be an issue with DNS clustering so I disabled DNS clustering and this was the error:
27/Mar/2024 02:06:21 +0000] [PID 3199861] Restoring domain domain.com (including DNS zone file)
[27/Mar/2024 02:06:22 +0000] [PID 3199861] [ERROR] Failed making API Call to cPanel/WHM (cpapi2). Error: (XID kmyz37) Died at /usr/local/cpanel/Cpanel/Admin/Modules/Cpanel/subdomain.pm line 176.
Jetbackup suggested that this was a cPanel issue, not a Jetbackup issue.
The only way to get the addons/subdomains restored was to delete the existing entries from the DNS zone file.
Is this a known bug?
-
Official comment
Hello,
Anton from JetBackup here! We reached out through your ticket with us and we appreciate your cooperation while we narrowed down what's causing your restore issue. As advised on your ticket, we found an issue with DKIM TXT records for sub/addon domains from the primary zone for this account preventing JetBackup from restoring your sub/addon domains.
We were running into the "domain already exists" error when we tried to execute `cpapi2 --user=<user> AddonDomain addaddondomain` and `/usr/local/cpanel/bin/uapi --user=<user> SubDomain addsubdomain` commands during the restore process since we restore the primary domain and primary zone first before restoring any of the sub/addon domains.
This would also prevent any email/email accounts associated with the affected sub/addon domains from getting restored since these domains failed to be restored.
As a workaround, we needed to remove the corresponding DKIM TXT entries for the affected sub/addon domains from the primary zone and then restore the sub/addon domains and corresponding email accounts in JetBackup.
With that said, we also have an open case JB5-CP#190 to address this issue. We also like to thank the cPanel team for assisting us narrow down what's causing this issue.
Please visit changelog.jetbackup.com to get the latest updates and bug fixes in JetBackup!
Best Regards,
Anton
JetApps Team. -
Hello Unnamed User,
Once you clear the conflicting DKIM entries from the primary domain's zone, can you try restoring the affected addon/subdomain and corresponding email account(s) by selecting them via the restore modal (advanced settings):
This should ensure that you're only restoring the affected items that failed to restore.
Thank You,
Anton
JetApps Team2 -
Hopefully antonJetApps will have some more details for you!
1 -
Hey there! It isn't any bug that I've heard of. Let me reach out to the JetBackup team and I'll see what we can come up with for this!
0 -
I did reach out to JetBackup and they let me know they are still waiting for access to the server so they can check things on their end. They did let me know they would reach out to us directly if they think there could be a cPanel issue happening.
0 -
I gave them access to the server that night.
These were their responses in the ticket:
Please note that JetBackup 5 itself has no issues with restoring a backup when DNS Cluster is enabled.
JetBackup 5 is first creating the domain via the cPanel API, and is failing to create the domain due to the cPanel API error before we can attempt to restore the DNS zone.
This occurs entirely outside of JetBackup, but Domain "cruft" and/or problems with your DNS Cluster could cause the domain restore to fail. Domain cruft is files/folders for the domain left after termination by cPanel and is entirely unrelated to JetBackup.
You can use the cPanel, LLC developed "acctinfo" script with the --cruft flag to confirm whether domain cruft exists locally on the server:
https://github.com/CpanelInc/tech-acctinfo
Note that JetBackup 5 is already checking whether the domain exists on the server. If there's domain cruft, you can normally remove it from "WHM > Delete a DNS Zone".
Please let us know if you have any other questions or concerns.
==================================
If deleting dns entries resolve the issue it means, there are some entries remain on the server due to which you were getting those errors.
jetbackup do not have anything to do with the dns entries left on the server for any reason.
Feel free to contact us back if you need any further assistance.
====================================================
This was their last response :
Thank you for your patience. My name is Kevin from the Level 2 JetApps Support Team looking into your case. I understand that addon domains and subdomains that are a part of a DNS cluster are not being restored properly, and our team will promptly provide you with updates on our investigation as soon as they are available.
======================================
They logged into the server:
Time: Tue Mar 26 22:31:51 2024 -0400
IP: 178.128.246.11 (NL/The Netherlands/sshbox2.jetapps.com)
Account: root
Method: publickey authentication
Log line:
Mar 26 22:31:48 host9 sshd[3221159]: Accepted publickey for root from 178.128.246.11 port 40500 ssh2: RSA SHA256:xQE9/cj7T9pnJ+7ig40GYmacVXoFRGhSoQQuQJzocPA
=====================================
At 2:20 am I notified them that the server that crashed was back online and I was restoring the missing info using cPanel's transfer tool and the ticket was closed.
0 -
I did speak with the JetBackup team again and one of their team members is going to reply to this thread with more information soon.
0 -
Sorry if I am intruding on somebody else's request.
It's not really quite that, Anton, I get the same error
[17/Apr/2024 09:33:00 +0000] [PID 3004149] [ERROR] Failed making API Call to cPanel/WHM (uapi). Error: (XID ntett8) (XID 7jam7f) A DNS entry for the domain “blog.domain.tld” already exists. at /usr/local/cpanel/Cpanel/Admin/Modules/Cpanel/subdomain.pm line 176.
So I go ahead and remove the DKIM keys for subdomain from domain zone, it fails, then try again with removing ANY trace of the subdomain in the zone files. It still fails the same. Maybe because when I click on "retry failed items" it also redoes the MAIN domain DNS zone and automatically adds the subdomain THEN fails because "subdomain already exists".
Then, I would suspect the restore routine hasn't really been thought through proper...
Is there a real workaround for this or should we stop relying on jetbackup until you fix it ?
Thank you!
0 -
Hi antonJetApps. The bug is still present, I don't see the fix JB5-CP#190 in the changelog.
Is there an ETA for this?
Thanks in advance,
Ignacio
0 -
Pinging kevinJetApps as well
0 -
Hello imorandin,
After checking, I found that the case was moved to JB-Base #1891 and it is currently open. Our developers are continuing to look into the issue and will assign a milestone when they are sure that they can implement a proper solution.
Apologies for any inconvenience. In the meantime, please use the workaround provided by Anton:
"As a workaround, we needed to remove the corresponding DKIM TXT entries for the affected sub/addon domains from the primary zone and then restore the sub/addon domains and corresponding email accounts in JetBackup."
Best regards,
kevinJetApps0 -
kevinJetApps - thanks so much!
0 -
No problem, glad I could assist!
0 -
Thanks Kevin!
0
Please sign in to leave a comment.
Comments
14 comments