JOURNAL BACKUPS vs. TRADITIONAL INCREMENTAL BACKUPS

SM*ers,

Recently, I have been pondering over the concept of performing Journal based
backups vs. Traditional full incremental backups. Previously, before
upgrading to 4.2.1.15, which I was able to use the Journaling Service, one
of my NT file servers (NT 4.0 SPK6 ADSM 3.1.0.6) was taking well over 10
hours to process 413,000 files and backup 4,300 of those files (6.06 GB of
data).

Now after the upgrade to 4.2.1.15, I have seen a dramatic increase in
performance, from 10 hours to 35 minutes. After installing and running the
Journal based backups for a couple of nights I realized in the READMe:

"This compressed name does not logically identify a unique object. This can
be handled by setting the "incrthreshold" option which can (when doing full
filespace incremental ) result in such a "traditional" incremental.

When you move a directory, using Windows Explorer, to the recycle bin, the
filesystem API reports only a delete of this one object.  The files and
subdirectories under this directory are not expired.  If you restore from
the recycle bin, this subdirectory is not backed up again.

Restoring files causes the journal to record the change activity.  If the
restore is using the active backup copy, the change record is deleted from
the journal.  When restoring with a backupset, it is not possible (without
querying the server) to know if the copy of the file is the active backup
copy.  The net result is that if the next incremental is done using the
journal, these files will be backed up again.  This can be avoided by
performing an incremental with the -NOJOURNAL option."

So, tonight I will try the backup with the -NOJOURNAL option to perform the
Traditional incremental to see if I can still benefit from the performance
of just having a 4.2 client
vs. a 3.1 client!

Seems to me that the Journal Based backups is only really beneficial if you
have a file server with well over 1 million objects to process with under 5%
of those objects changing on a nightly basis!

Thanks,


Demetrius A. Malbrough
UNIX/Tivoli Systems Admin
dmalbrough AT ttiinc DOT com