• Resolved nadavs

    (@nadavs)


    Hello,
    It seems like encryption causes problems with backups. When using encryption, backups will randomly fail to upload to a remote destination. Furthermore, when the backup consists of multiple parts, the plugin will upload only the last part to remote storage. Without encryption, all parts are uploaded.

    Best regards,
    Nadav

Viewing 10 replies - 1 through 10 (of 10 total)
  • Plugin Support jimiero

    (@jimiero)

    Hello,

    Have you checked your error logs and see if there’s anything reported when that happens?

    Thread Starter nadavs

    (@nadavs)

    Nothing is reported. It just says:

    [2024-06-17 07:11:34] xcloner_scheduler.INFO: Encrypting backup archive backup_www.XXX.com-2024-06-17_07-11-sql-enc.tgz. [“CRON”] [] [2024-06-17 07:11:34] xcloner_encryption.INFO: Encrypting file backup_www.XXX.com-2024-06-17_07-11-sql-enc.tgz at position 0 IV [] [] [2024-06-17 07:16:35] xcloner_file_system.INFO: Cleaning the backup storage LOCAL on matching rules [] [] [2024-06-17 07:16:35] xcloner_file_system.INFO: Deleting backup backup_www.XXX.com-2024-06-17_07-11-sql-enc.tgz from storage system LOCAL matching rule [“BACKUP QUANTITY LIMIT xcloner_cleanup_retention_limit_archives”,”1 >= 1″] []

    And then it does nothing. This error apparently only happens where the archive is large (>400MB) or there are many tables. Sometimes it gives an archive of 66KB instead of 3GB.

    When I do a manual backup (“Generate Backup”), it works well.

    I tried increasing all php.ini settings to the maximum, since when the default values are set I get this error for large-database sites:

    Error Message: SplFileInfo::getType(): Lstat failed for /home/XXX/XXX.com/wp-content/backups-pNhXD//.xcloner/database-backup.sql

    Plugin Support jimiero

    (@jimiero)

    Hello,

    Please also check your website server error logs, not just XCloner logs.

    Regards

    Thread Starter nadavs

    (@nadavs)

    I did, there are no relevant error logs for php or the server itself.

    I tried disabling the cron and running it manually every 10 minutes, still doesn’t work. Set the php.ini settings to server defaults, still doesn’t work. It starts archiving and fails.

    The backup_files.csv and database-backup.sql files are generated well. Something goes wrong with archiving (the log says it archived and then stuck at encryption, but the archive has a size of zero).

    Plugin Support jimiero

    (@jimiero)

    Try restoring a copy of the website on a different server or locally and try again and see if works in there, I’m not able to reproduce the issue here.

    Thread Starter nadavs

    (@nadavs)

    It works for some websites and doesn’t for others (on the same server). Everything works for “Generate Backups”, but scheduling fails for the problematic websites.

    The websites are fully functional except these weird scheduled backup issues. Seems like a file list of more than 2GB causes trouble when using the scheduler.

    Thread Starter nadavs

    (@nadavs)

    I may have found a solution: it turns out that large tables (> 40k records) made it crash. I deleted all records from those tables (mostly Wordfence junk) and it worked.

    There was also an error when doing multi-part archiving, but I solved it by increasing the file-splitting limit to a very large number.

    However, seems like I don’t get all files backed up. The final archive is smaller than the one with a generated backup.

    • This reply was modified 3 months ago by nadavs.
    Thread Starter nadavs

    (@nadavs)

    Solved: ModSecurity deleted the temporary directory mid-operation. Disabling it worked.

    Plugin Support jimiero

    (@jimiero)

    Glad to hear your issue is sorted, thanks for sharing the cause.

    Rgards

    Thread Starter nadavs

    (@nadavs)

    Final update: ModSecurity wasn’t the problem. It’s the way the plugin handles crons: sometimes, it schedules the “do_shutdown” function, which deletes temporary files. If a backup is underway, it will delete the file list, which stops the archiving process. The solution was to run manual crons with enough time for a run to complete.

Viewing 10 replies - 1 through 10 (of 10 total)
  • You must be logged in to reply to this topic.