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'.
