> additional licenses...

Developing the support for as yet unsupported clients would sell more client
licenses, and is a much bigger issue here.  If I had to vote on requirments, new
clients that my people need would get my +5.  A PITR requirement would get
something much less.

> In researching this, I found out that ARCHIVE/RETRIEVE does not preserve
> symbolic links on Unix systems.  This makes ARCHIVE unsuitable for doing
> snapshot backups for the purpose of later point-in-time restores.

This is a justification for a feature for that CLIENT's ARCHIVE/RETRIEVE, not a
justification for adding marginal features to BACKUP/RESTORE.

> If you determine that you need to restore your disk quickly enough (before
> another incremental backup has occurred), then restoring from the last
> incremental backup is satisfactory.  However, if you do not detect the
> problem until after one or more incremental backups have occurred, then
> restoring from the last backup is not satisfactory.  This is where point-
> in-time restores are needed.

You always have the ability to create multiple versions and restore those
versions.  The client I test with displays them very well.

> 1) Viruses.
>
> 2) Unix hackers...cost
>
> 3) Software bugs.    If files are corrupted, but this is not detected until
>  days later, then point-in-time restores would be useful to recover from this.
>
> 4) Human error.  Humans make mistakes.  They don't always detect them right
>   away.  If days pass before the problem is detected, then a point-in-time
>   restoral would be very useful to recover from this.


Points 1 and 2 arguments are more about the current state of affairs in the
distributed environment and not about backup.  Point 2 is a damning condemnation
of unix security and should be noted as such.  Using backups as a mechanism to
protect oneself against the almost eventual unix hacker is....well it wouldn't
get by auditors.  The ultimate cruelty delivered by a hacker would be to delete
or corrupt those very backups.

Points 3 and 4 are just as valid in the mainframe environment, which does very
well with version numbers.  Point 4 is lamentable, because I know of no number
of versions to maintain or length of time to maintain a backup which will
adequately address every case of UIUC.

Dean