Alarming message in backup zip file

Help! (Home for newbies)
1 
 zip I/O error: Broken pipe
 zip error: Output file write failure (write error on zip file)
```
SYSTEM INFORMATION
OS type and version Debian Linux 13
Webmin version 2.621
Usermin version 2.521
Virtualmin version 8.1.0 GPL
Theme version 26.22
Apache version 2.4.66
Package updates All installed packages are up to date

the backup obviously failed. :shaking_face:

yet the next days’ backup progressed (finally) without error

it is concerning (it took an awful lot of digging into the backup log to find the above notice) the log is very big (with all the VS ‘added’ - OK) until failing at near the end.

1 Like
2

What if you change the backup from zip to gz
 does it go faster?

3

no idea. this is a scheduled daily backup that has been running on a production server for many months without a hitch

so i’d rather not tamper

i was just rather shocked to find it broken. plenty of space and adequate memory - the backups are not kept very long before offloading elsewheree.

despite all the “additions” appearing to be completed for each VS it just seemed to fail when they were combiined

4

if not already a feature, VM/WB sould send an email of the errors to the admin email address (the default or specified one)

5

I think it is there already. I have my dailies are set to email on failure. My once per week full emails regardless of status. A reminder to do my weekly rsync of the backup directory.

6

yes, that is how i found out it failed.

the only (slightly disappointing thing) with many VS on this VM is having to wade through all the “success added” messages to find the failure reason.

but again last night’s at least worked

still does not explain why the previous one failed to build the zip file.

(i was wondering if this was another issue with that /tmp/
 file being created to build the final zip - even though there is sufficient memory/space there is quite a busy CPU/activity spikes at around the time this schedule backup is run)

7

is the email completely vanilla? Maybe adding links into the email to open the logs at the relevant place.

8

yes, that might help especially as the fail only gets exposed long after the actual impact (like i suspect most folk i try to run these backups when the server and me are not watching - quieter time :shushing_face: )

9

I didn’t understand what is alarming here ?
It happens a backup fail. As long as you are warned about it, it seems fine no ?

So yes indeed it’s probably annoying to have to check the log and it would have been better to get the error first, but it’s not so alarming :slightly_smiling_face:.

Then concerning the fail itself, you gave us the problem “Broken pipe”. If the pipe get broken it can’t simply not zip it (Still, as @ID10T said, the individual backup shall be fine).

Isn’t it what we usually get when it timed out. Probably too slow to zip the whole, or a “connection” reset. Sometime it happens, nothing bad, especially if all the individual backup are working.

You also said it never happens before, but what was the size of the whole zip 8 months ago compared with today ?

10

and has not happened since either.

i do not think size matters here - it has been bigger and smaller at times due to changing numbers of VS - but speed may be am issue as although the VM is at a theoretical quiet time it could still be getting other inputs that could delay - it currently is about 1G

the reason why it was alarming was that it was unexpected and not fully unexplained.

anything other than zip is not an option. most of the clients on this VM use MS and cannot/will not use other compression methods.

1 Like