@usmannasir said:
File does not seem OK, need to check.
Just tried again and it works well. This time took the latest backup and renamed to m.tar.gz
Does file name affect restore? Like 03_Sep.tar.gz
Another minor issue is that the MAIN panel that creates scheduled remote backup does not delete the file in /website/backup/ after sending to REMOTE panel.
I have the same problem, I can not have a backup. panel says it is ready but the file is empty size. On the other hand, there is no .gz file in my ftp. how can I fix it? thank you.
@CyberPanel i can confirm the scheduled backups are not able to be restored (CRC fail, or restores incompletely), and after backup the source panel does not delete the .tar.gz so it accumulates.
It’s still “back up” everywhere in the UI, not “backup”? I guess it only affects grammar Nazis, but still. “Back up” = to move backwards, especially for a vehicle to do so.
Ex. that beeping sound indicates that the truck is backing up. “Backup” = a copy of a file or record, stored separately from the original, that can be used to recover the original if it is destroyed or damaged.
set up a new panel to remote transfer over so I can leave 2 x vps free to get it checked, again similar issue like before. It’s always the same few issues with scheduled backup + remote transfers that keep rotating around.
Current remote transfer workaround is to create backup to home (/home/www/backup/) and then scp over to new vps (/home/backup/) and then restore.
No longer have the luxury of time to repeat these tests.
Will be on a hiatus to learn about cronjobs from scratch.
I recently did remote transfer for a user and it went fine and no other reports except you. I am not sure if CloudLinux is interfering with the backup process on your server.
@CyberPanel replied to a few days old ticket as i was preparing to shift production out. would you mind taking a look at it for a better idea of backup issues or is access not needed any more?