System Backup FTP fails

Otherwise wouldn't just recovering the user backups restore all the DNS.
Yes that is correct. On backup/restore that normally is also in the user backups.

But having a backup is good anyway. Not that long ago I deleted around 20 domains by accident, from a slave server in the multi server setup. But problem was that multiserver was not off yet. It was done because I had to move them to the master server otherwise they wouldn't be accepted because of existance already. But as said. Forgot to turn of the multiserver before.

So all dns from these domains were deleted from both slave as well as the master. And some domains have customized DNS. So I had working domains (not deleted) and non working domains and I had to find a way to rebuild them.
Because domains and accounts were still present but named info not anymore.
There is a script which only just rebuilds all to default, which I couldn't use as I had still working domains also with custom content in the DNS. And that script uses default values.

I had some older backups which I couldn't restore because sites were updated and databases had new content.
So I only used the dns stuff from that old backup and with the perl -pi command I changed some content and added them again (manually) in the named.conf and everything was working again.

Since then before I start doing moving stuff I always create a backup of the named.conf and all dns zones, just to be sure. :)
I wasn't aware that was in the system backup too as I never use that.

I do the same as you. I also have a few documents. Setup and a few customisations which are done every time I build a server so every server has the same setup. Just like you.
 
I have 2 servers that simply act as nameservers and one retrieves (cron job) the zone files from each DA server and builds the named.conf file based on those zone files and of course reloads. The second retrieves from the first nameserver and does the same thing. They also do not delete zone files. So I always have a copy somewhere.
 
I can also confirm it works again after installing ncftp :cool: Thanx @floyd
@Richard G : you can perform a new backup as many times as you want in another way too. All you need to do is to remove the current backup directories and files, usually stored in /backup by date. Just remove today's directory and you can try again ;)

Last but not least: I also use a document to (re-)install every server the same way, although my latest server runs Almalinux instead of CentOS. And as I do not perform installations every year, I can image some things might change, like abandon ncftp. No problem, but you won't expect a standard DA feature stops working because of that ?

Thank you both for testing!

Regards,
Danny
 
Just remove today's directory and you can try again ;)
Yes thank you. But I was expecting this to work the same as the user backups, so just adding a -1 or -2 and -3 behind it or something, because you can also create lots of user or admin or reseller backups without the need to remove backups (unless disk get's full).

So I was a little bit surprised that this did not work the same way.

Also I was aware that they start using curl instead of ncftp but was not aware it wasn't installed anymore and that the system backup was still using it, so also different from the normal backups. One would expect backups to work all kind of the same way. :)

Anyway glad it's fixed. Adjusting my documents now to install ncftp again on fresh installation.
 
I ran in to this thread for having the exact same problem. My installation is from 16 august this year on AlmaLinux 9, so in the couple of months between this problem was not addressed. After installing ncftp, system backup worked as it should.
I remember there used to be a check in DA if ncftp was missing. :(

Why isn't ZST used? The System Backup uses GZ, while Admin Backups/Transfer uses zst.

Should I be concerned about?: Dumping database sys: nice: ‘/usr/bin/mysqldump’: No such file or directory

/usr/local/sysbk/sysbk -s
With missing ncftp:
Code:
Dumping database sys: nice: ‘/usr/bin/mysqldump’: No such file or directory
                                                             [ COMPLETED ]

                                                             [ FAILED ]

/usr/bin/ncftpput not found, aborting...
Performing cleanup operations:                               [ COMPLETED ]
With ncftp:
Code:
       Dumping database sys: nice: ‘/usr/bin/mysqldump’: No such file or directory
                                                             [ COMPLETED ]

//backup/10-03-24/custom/etc/exim.conf.tar.gz:           8.39 kB  522.30 kB/s  m.conf.tar.gz:
//backup/10-03-24/custom/etc/exim.conf.md5:             81.00 B     7.62 kB/s
...
//backup/10-03-24/mysql/sys.sql.tar.gz:                128.00 B    11.89 kB/s
//backup/10-03-24/mysql/sys.sql.md5:                    73.00 B     6.81 kB/s
                                                             [ COMPLETED ]

Performing cleanup operations:                               [ COMPLETED ]
 
Thank to this thread, it helped me solve part (ncftp) of my issue with the System Backup function.

But I'm running into another problem in the next step.
Transfering named.conf.tar.gz to "external IP": ssh: connect to host 0.0.7.230 port 22: Network is unreachable
I can ping the destination IP.
When I make a connection to the external location manualy it gets connected after entering the password: ssh unsername@externalIP -p 22
This server has 2 network adapters, one for the connection to the internet, the other for the backup over a local LAN.
Should I add something to the settings to use the local netwrk connector?

What I've also seen is that in the settings in DA is when I enter the password which contains a $ after saving is, it shows as \$ in the config file of conf.sysbk
On the old server it hasn't got the \.

Another thing I've noticed, is that the settings GUI shows this link: Link to id_rsa.pub (should be inserted into ~/user/.ssh/authorized_keys) wich shows an page with "Unable to edit file".
I'm logged in DA as admin, but the setting in conf.sysbk shows PRVID_FILE="/root/.ssh/id_dsa".

And the last thing I've noticed, that even after I did:
da config-set zstd 1
da config-set backup_gzip 2
systemctl restart directadmin
The backup files are still gzip.

The server runs on Alma Linux 9.6
 
Last edited:
Back
Top