I have a Windows2000 client who has well over 5 million files that we
ARCHIVE every week for offsite-vaulting purposes. Why we don't use the TSM
primary storage pool --> copy storage pool methodology for this client would
take a while to explain. At any rate, due to the large # of files (currently
approx 5 million) and the large size of the backup (approx 175GB), the
ARCHIVE job takes a couple of days to complete.



I thought about moving the client weekly full to an online image backup, but
with image backup, you do not get file-level granularity during a restore. I
was thinking about using the journaling engine, but my thoughts are that it
would probably only help the performance of the daily incrementals, not an
ARCHIVE job. Is this correct, or would enabling the journaling engine help
my ARCHIVE performance? If so, any estimates on how much improvement and
also, are there any pitfalls with this setup? I have just started playing
with the journal engine in the lab (unfortunately, I do not have a machine
with 5 million files totaling 175GB of data in my lab to test with)



I would like to find a fix that allows offsite vaulting of data with a
different retention policy than the onsite data, as well as allowing
file-level granularity. I don't want to use backupsets for a couple of
reasons, basically, they take too long to generate, thrash the database, tie
up tape resources, and you cannot do per-file restores from a backupset from
the GUI (or at least the last time I checked you couldn't). Plus, if the
GENERATE BACKUPSET fails due to any DB problems/conflicts, you must start
the GENERATE BACKUPSET job all over again.



I guess one option would be to have one instance (dsm.opt) on the client
with a scheduler service running whose data is assigned to an onsite mgmt
class and then have another instance (dsm1.op) with a separate scheduler
service running whose data is assigned to an offsite mgmt class, but this
seems a little 'clunky'.