What should be scary here is not that your backups are failing, but the
fact that you might not be able to restore, regardless of whether or not
your backups are working. And the ability to restore is the whole point
of backup.

We had one of those old, memory-starved, 32-bit clients (Solaris) who
had somehow gotten 18,000,000 files in one filespace backed up, with
most of them in one flat directory. (It was BlackBoard.) We were going
to move a disk subsystem by restoring the bulk from TSM and then
catching up incrementally. There was no way a 32-bit TSM client could
touch that 18,000,000 file filespace for restoring. There's not enough
room in a 32-bit virtual address space to hold the entire list. There is
no such thing as "memory efficient restore". I wish there was, because
in the 32-bit clients it is possible to back something up which cannot
be restored, if it has many millions of files.

We were going to restore in parts, to another machine that had a 64-bit
client, and move the restored files over by NFS. But then we decided on
a completely different strategy for moving this data, so I never had to
do it.

This backup failure might not be your worst problem here. Run a test to
make sure a restore (either partial or full) is possible, even after you
find a way around the backup issues.

Roger Deschner      University of Illinois at Chicago     rogerd AT uic DOT edu
======I have not lost my mind -- it is backed up on tape somewhere.=====


On Mon, 14 Oct 2013, Richard Rhodes wrote:

>>
>> We were able to get to a 64bit OS during an upgrade that made all of
>> the memory problems go away.
>
>This has been our experience also.  Not completely, but mostly, and
>especially if it has lots of memory.  It's difficult to convince many
>people that the biggest and hardest hitting application on their server
>might be the backup software, and to figure that into their requirements.
>
>Rick
>
>
>
>-----------------------------------------
>The information contained in this message is intended only for the
>personal and confidential use of the recipient(s) named above. If
>the reader of this message is not the intended recipient or an
>agent responsible for delivering it to the intended recipient, you
>are hereby notified that you have received this document in error
>and that any review, dissemination, distribution, or copying of
>this message is strictly prohibited. If you have received this
>communication in error, please notify us immediately, and delete
>the original message.
>