How to access legacy backup configuration in cPanel ver 78

[AndyB78]

Hi,

I'd like to use the legacy backup system in cPanel ver 78 but it's hidden due to deprecation.

I need to do this because the new system will generate backups continually and will gradually fill up the entire available space if the network and NAS are not fast enough to keep up with the backup tarballs generation. So it's best to just use the old system where each account is backed up only after the previous one has been uploaded to the NAS.

How can I re-enable the legacy backups?

Thanks!

 

[AndyB78]

I have managed to access legacy backup by doing these:

touch /etc/cpbackup.conf
echo "BACKUPENABLE yes" > /etc/cpbackup.conf
mv /var/cpanel/caches/_generated_command_files{,.backup}

However I have not managed to start it with the /usr/local/cpanel/scripts/cpbackup line in crontab (nothing happened). But it started with a manually run /scripts/cpbackup. But I don't understand what's the difference. I've done a diff on the 2 files and there's no difference.

 

[cPanelMichael]

Hello @AndyB78,

However I have not managed to start it with the /usr/local/cpanel/scripts/cpbackup line in crontab (nothing happened). But it started with a manually run /scripts/cpbackup. But I don't understand what's the difference. I've done a diff on the 2 files and there's no difference.

I've been unable to reproduce this behavior on a server running cPanel & WHM version 78.0.18. Can you browse to WHM >> Legacy Backup Configuration and click Save at the bottom of the interface to see if that addresses the issue? If not, can you check if any entries appear in /usr/local/cpanel/logs/error_log when executing the /usr/local/cpanel/scripts/cpbackup command?

Thank you.

 

[AndyB78]

Hello @Michael,

Thank you for your investigation. I have further investigated the problem and I found out my initial report was flawed. This now seems to be a crond problem.

The relevant crontab line is this:
53 21 * * * /usr/local/cpanel/scripts/cpbackup

So it should trigger at 21:53. But it doesn't. It triggers at 23:53:
Mar 29 23:53:01 CROND[4773]: (root) CMD (/usr/local/cpanel/scripts/cpbackup)

So this is why the croned script didn't trigger. The cron timing is wrong but I have no clue why. The hour is correct on the server:

[[email protected] ~]# date; tail -1 /var/log/cron
Sat Mar 30 01:14:56 EET 2019
Mar 30 01:14:01 CROND[16104]: redacted

So at least the crond log is in sync with system time. I have just restarted crond service and I'll see if this fixes the offset.

 

[cPanelMichael]

I have just restarted crond service and I'll see if this fixes the offset.

Let me know if that helped. If not, try adding a root cron job like the one below:

5 * * * * date >> /root/cron.date

You can adjust the "5" value to whichever minute is just beyond the current time. Then check /root/cron.date to see if crond is reporting the correct date.

Thank you.

 

[AndyB78]

Let me know if that helped. If not, try adding a root cron job like the one below:

5 * * * * date >> /root/cron.date

Thank you.

Hello,

I forgot to update this thread earlier: the crond restart fixed the problem. Sorry for the delay!

I have one question about the new backup system (not the legacy one). I know it is generating backups locally on the server and then transports them remotely in time. But does it make any tests (like prior to generating the next account tarball) so that it doesn't fill up the entire local folder if the network is not fast enough?

 

[cPanelMichael]

I have one question about the new backup system (not the legacy one). I know it is generating backups locally on the server and then transports them remotely in time. But does it make any tests (like prior to generating the next account tarball) so that it doesn't fill up the entire local folder if the network is not fast enough?

Hello @AndyB78,

The backup process and the transfer process use separate queues. If each backup completes much faster than each transfer, backup files can accumulate on the server and fill the hard drive.

There's a disk space check to help prevent this from happening, but it occurs at the start of the backup generation process as opposed to in-between each individual account backup generation. You can configure the disk space check by adjusting the following option in WHM >> Backup Configuration:

Check the Available Disk Space

Additionally, while mostly unrelated to your specific question, the following document includes a good overview of how to configure backup retention settings:

Backup Retention Behavior - cPanel Knowledge Base - cPanel Documentation

Thank you.