Missing files in backup

Resolved andyhenderson2
(@andyhenderson2)

3 weeks, 1 day ago
I’ve been using version 5.6 for a while now. I have a slow-moving site that I backup to the site’s server. I then have an automated procedure that downloads the backup file and stores it offline. My process includes two integrity checks:
1. The downloaded backup file must be a valid zip archive
2. Its size must be greater than a value I provide.
Last night’s backup passed the zip check but failed the size check.

I have backup logs going back to 20th March and they all show the backup zip to be 61.4 Mb – that’s the same size as my saved copies. Last night’s backup was recorded in the BackWPUp log as 48.99Mb but the saved copy was just 12.4Mb!

The log of the most recent successful backup shows:
```
[INFO] BackWPup 5.6.7; A project of WP Media
[INFO] WordPress 6.9.4 on https://haylingcycleride.org.uk/
[INFO] Log Level: Debug (translated)
[INFO] BackWPup job: Files & Database; FILE+DBDUMP+WPPLUGIN
[INFO] Runs with user: (0)
[INFO] BackWPup job start with link is active
[INFO] BackWPup job started from external URL
[INFO] PHP ver.: 8.3.30 (64bit); cgi-fcgi; Linux
[INFO] Maximum PHP script execution time is 30 seconds
[INFO] Script restart time is configured to 45 seconds
[INFO] MySQL ver.: 5.7.42
[INFO] Web Server: Apache
[INFO] cURL ver.: 7.74.0; OpenSSL/1.1.1w
Folder list appears here
[06-Apr-2026 02:07:19] Backup archive created.
[06-Apr-2026 02:07:19] Archive size is 61.48 MB.
[06-Apr-2026 02:07:19] 2853 Files with 109.24 MB in Archive.
[06-Apr-2026 02:07:19] Restart after 15 seconds.
[06-Apr-2026 02:07:20] 1 old log deleted
[06-Apr-2026 02:07:20] Job done in 327 seconds.
```
The log of the problem backup shows:
```
[INFO] BackWPup 5.6.7; A project of WP Media
[INFO] WordPress 6.9.4 on https://haylingcycleride.org.uk/
[INFO] Log Level: Debug (translated)
[INFO] BackWPup job: Files & Database; FILE+DBDUMP+WPPLUGIN
[INFO] Runs with user: (0)
[INFO] BackWPup job start with link is active
[INFO] BackWPup job started from external URL
[INFO] PHP ver.: 8.3.30 (64bit); cgi-fcgi; Linux
[INFO] Maximum PHP script execution time is 30 seconds
[INFO] Script restart time is configured to 45 seconds
[INFO] MySQL ver.: 5.7.42
[INFO] Web Server: Apache
[INFO] cURL ver.: 7.74.0; OpenSSL/1.1.1w
Folder list appears here
[07-Apr-2026 03:18:48] Backup archive created.
[07-Apr-2026 03:18:48] Archive size is 48.99 MB.
[07-Apr-2026 03:18:49] 2853 Files with 109.24 MB in Archive.
[07-Apr-2026 03:18:49] Restart after 14 seconds.
[07-Apr-2026 03:29:04] 1 old log deleted
[07-Apr-2026 03:29:04] Job done in 5231 seconds.
```
Note Both backups show the same number of files with the same file size, but the zipped file sizes are different. The only clue I can see is that the run time for recent backups has consistently been around 320-330 seconds, but the problem backup appeared to take 5231 seconds. Both logs show restarts after 43/44 seconds in virtually the same places, but there’s big time jumps between some of the restarts in the log of the problem backup including the final restart as shown above.

The site’s error log is empty. In the UK we activated daylight saving on Sunday 5th, going from GMT to GMT+1 but we’ve had two successful backups since then.

It looks like BackWPUp saved the database and plugins to the zip but then failed to write the files section without throwing an error. But that doesn’t explain why BackWPUp thought the zip size was 48.99 Mb – that’s neither the expected size (61.5Mb) nor the actual size (12.4Mb).

I’ve since re-run the backup using the normal procedure and it went as expected.

I hope that’s of use,

Andy

Viewing 7 replies - 1 through 7 (of 7 total)

Plugin Support Saransh
(@saranshwpm)

3 weeks ago
Hi Andy,

Thank you for the detailed explanation, this is really helpful.

Just to understand this better, could you please check a couple of things:
- Are you able to extract both backup files (the normal one and the problematic one)? It would be helpful to compare and see if any main folders/files are missing in the smaller archive.
- Could you please share the full log of the problematic backup (after hiding any sensitive information)? You can use a service like Pastebin to share it.
Also, just to confirm:
- Is this issue happening consistently with all scheduled backups?
- Or was it a one-time occurrence?
- If you run a manual backup, does it complete correctly?
This will help us determine if this is related to a specific run or something more consistent.

Looking forward to your update.
Thread Starter andyhenderson2
(@andyhenderson2)

3 weeks ago

>>>Are you able to extract both backup files (the normal one and the problematic one)? It would be helpful to compare and see if any main folders/files are missing in the smaller archive<<<

All the folders from the ‘Files’ section of the backup including: uploads, themes, and a folder included in the ‘Include in backup’ section. As I said “It looks like BackWPUp saved the database and plugins to the zip but then failed to write the files section without throwing an error”.

>>>Could you please share the full log of the problematic backup (after hiding any sensitive information)?<<<

I’m reluctant to do that because I’m uncertain how the log information can be exploited. However, I’ve done a line-by-line comparison and all expected folders appear in both logs. The only difference is that the restarts occur in slightly different places (as you would expect) and there are extended time gaps following some of the restarts. I’m happy to supply the full logs, just not in a public forum.

>>>Is this issue happening consistently with all scheduled backups? Or was it a one-time occurrence?<<<

It was a one-off. We’ve performed two backups successfully since the problem one – we didn’t change any settings.

My best guess would be something at the server caused the extended delays following restarts and that has upset BackWPUP. My biggest concern is that BackWPup didn’t detect the issue even though there was a mismatch between the reported size of the zip (48.99 Mb) and the actual size (12.4Mb).

I think I spotted a further clue. The normal file size is 61.5Mb, the actual size of the problem backup was 12.4Mb. The reported size of 48.99Mb seems to be the size of the missing files. In other words, it’s reporting the size of the files it didn’t back up.

Andy
Plugin Support Saransh
(@saranshwpm)

3 weeks ago
Hi Andy,

Thank you for the detailed follow-up.

Yes, this is quite strange, especially since the backup completed without any clear error, but the files section was not actually written to the archive.

Your observation about the size difference is also interesting, it does seem like the reported size might be based on what was expected rather than what was actually written.

Regarding the logs, I understand your concern about sharing them publicly 👍

No worries on that.

Could you please check one thing in the log:
- Around the points where you see the “Restart after X seconds” messages, do you notice any specific warning or message printed just before or after? For example something like inactivity, timeout, or delays (e.g. gaps of several minutes between entries).
Even a small snippet from those sections (without sensitive info) would help.

Since this was a one-off and subsequent backups are working fine, it does point towards a temporary interruption.

Thanks again for digging into this 👍
Thread Starter andyhenderson2
(@andyhenderson2)

3 weeks ago
>>>Around the points where you see the “Restart after X seconds” messages, do you notice any specific warning or message printed just before or after? For example something like inactivity, timeout, or delays (e.g. gaps of several minutes between entries).<<<

Like I said there were extended time gaps. For example:
```
[07-Apr-2026 02:06:18] Archiving Folder: ...
[07-Apr-2026 02:06:20] Restart after 43 seconds.
[07-Apr-2026 02:55:47] Archiving Folder: ...
```
No warnings or other messages. The backup reported successful completion although it clearly wasn’t.

Andy
Plugin Support Saransh
(@saranshwpm)

2 weeks ago

Hi Andy,

Thank you for checking and sharing that detail.

The gap you pointed out is quite significant, and it does suggest that the process was interrupted and then resumed much later. However, since there are no warnings or errors logged around that point, it’s difficult for us to pinpoint exactly what caused it.

Given that this was a one-off issue and your subsequent backups have completed correctly, it does seem like a temporary interruption on the server side rather than a consistent problem in the backup process.

At this point, there isn’t a clear way to debug further unless it happens again.

If you do notice this behavior again, I’d recommend reaching out to us directly via the Contact Support option in the plugin so we can investigate it more closely with fresh logs and timing.

For now, I’ll go ahead and mark this as resolved, but feel free to reopen or reach out anytime if it reoccurs.

Best regards,
Thread Starter andyhenderson2
(@andyhenderson2)

2 weeks ago
I think you missed my main point. There should be an integrity check at the end of a backup run to compare the calculated zip size to the actual one. That would have flagged the error. I would have known nothing about it if I had not built a check of actual size versus expected size into my process.

Andy
- This reply was modified 2 weeks ago by andyhenderson2.
Plugin Support Saransh
(@saranshwpm)

1 week, 6 days ago

Hi Andy,

Thank you for clarifying your point, that makes sense.

BackWPup does perform checks during the backup process, but I agree with you that in this case the mismatch between the reported and actual archive size should ideally have been detected and flagged.

I’ve shared your findings with our developers so they can review this behavior more closely and see if improvements can be made around this final validation step.

Thanks again for pointing this out, it’s very helpful 👍

Viewing 7 replies - 1 through 7 (of 7 total)

You must be logged in to reply to this topic.