Scheduled Backup Failed

[dansoftware]

Can you share what action you performed to fix it?

Look above:

I updated to the latest beta version: build 16.0.3.525. There is a change in it: "Added validation for FTP paths with spaces." But the problem still exists. I have solved it by disabling "Recordings (Backup and Restore will take longer)".

If you are ready to debug the problem I can provide you access to the PBX temporary.

 

[AWS2P]

@JohnS_3CX
On my side i changed proftpd version to 1.35e on my Freenas server and now i've no more problems with backups.

other bad thing when i got zero bytes file created on ftp side, 3cx checked that i've done a succesfull backup and send me notification email , but in fact i've just an empty shell, the 3cx verification procedure is not strong enough to trust the result of the backup .
Don't know if for now in V16.2 checks have been improved

 

[JohnS_3CX]

Thanks

I think disabling recordings is not a solution if you do actually want them included in your backup. You should be able to get them to work.

Sounds like your FTP times-out while the backup is being prepared and transferred. I used filezilla as my ftp server, set timeout to 0 and had no issue with a 7GB file. If i leave the default timeouts, I get the same error as you, indicating that the FTP session ends prematurely and the pbx cannot continue. Your FTP server should be ok once you find a way to increase the session timer.

 

[dansoftware]

I think disabling recordings is not a solution if you do actually want them included in your backup. You should be able to get them to work.

I red what is included in the recordings carefully. I do not need them really.

Sounds like your FTP times-out while the backup is being prepared and transferred.

Thanks for the hint.

 

[SweetAction]

This is a well known issue - see: https://www.3cx.com/community/threa...f-call-history-is-selected.59897/#post-252144

Boils down to timeouts on the ftp server side

 

[AWS2P]

No it's not only a story about timeout settings, i've done this change in first with no more results, my case was a real bug between Proftpd and 3CX ftp client embeded

 

[JohnS_3CX]

For Debian you can also consider vsftpd

https://www.3cx.com/docs/ftp-server-pbx-backups-linux/

 

[AWS2P]

I'm not Debian but Freebsd

 

[dansoftware]

For Debian you can also consider vsftpd

You should change algorithm in internal 3CX FTP client instead advising to modify "data_connection_timeout=3600" in vsftpd configuration. 3CX should open a test connection to FTP server for short time before starting the backuping just in order to be sure that it is accessible. Connection should be opened again when 3CX is ready to upload an archive.