🚀 go-pugleaf

In article <davecb.726001056@yorku.ca> davecb@nexus.yorku.ca (David Collier-Brown) writes:
>  I tend to assume a normal operations secedule of backups when I
>discuss mailhubs.  

So what? Another red herring. Talk about mail, not backup schedules.

>  However, I'm discussing mail, not acts of god.  

Turning a system off is not an act of God. The same result would have
occurred had my mailhost been turned off as was the original recipient
system.

>  My operator restores the backup that cron took, and the mailer
>delivers the bounce message. Several days late.

Pay attention, Dave. Why should an operator restore a backup for a
system when the disk itself isn't damaged? Restoring from tape would
lose information -- everything that came in since the backup was done.
Or did you ignore the fact that it was a disk CONTROLLER and not a disk
that died?

Just what information do you think would make it onto a backup tape
between the time the system died and it being fixed? Mail that hadn't
yet been received certainly wouldn't make it to the backup tape. Or did
you ignore the fact that both of the recipient systems were already down
when the mail and bounce were sent? 

But, since you seem to be fixated on backups, here is a trivial example
of mail being lost, involving backups:

	Your cron program does a backup.
	Mail for one of your subsidiary systems comes in.
	That system is being backed up, sorry, can't deliver right now.
	Your system puts the mail into the store-and-forward queue.
	A "Dash-10" falls on your system.

Did the mail get to the recipient? No.
Did an error message get sent back? No.
Is that "reliable"? Hardly.