TSM Journalling for Image Backups

[GIBIN]

I have a Windows filesystem with over 2 million files and perform backup using image incremental backups .
Each time the image incremental backup runs all the 2 million files are rescanned and takes a very long time for the backup to complete although the data backed up is quite small.

Is it useful if i enable journalling on this filesystem ? Because I am not sure if image incremental backups will make use file journaliing .


has anyone used journallling with image incremental backups ?

tsm server v6.3.2
tsm ba client v6.3.15

backup command
----------------------
dsmc backup image D: -mode=incr


client opt file:
------------------

DOMAIN.IMAGE D:
SNAPSHOTPROVIDERIMAGE VSS

Exclude "*:\...\*"
Include.image D: 3mth_grp1_MC

[moon-buddy]

A good question.

Haven't tried this. All I can say is run an experiment and we will love to hear the results.

[GIBIN]

Tried it .. enabled journalling for the FS ,but makes no difference .Image incrementals do not make use of the journalling stats before running entire scan on the file system.Each time image incrementals run each file is scanned and verified with the tsm database .

From the IBM docs , i thought image backups were more of a block scanning thing rather than file.

[MKoehlerRoss]

Hello GIBIN,

I saw your thread and was interested in the same question. How to handle large filespace on clients.

I also tried out what tsm can do for us so i sat up an 6.4 client with an 6.2.3 server.

the windows client is 2012.

I took an image of the data partition. Afterwards I do an img incremental . last i let the normal incremental backup run.

The img incremental is very fast but seems to analys client and server data. the normal incr. run als slow as always.

the only benefit i could see there, that you will take an image of your big partition on weekends and let the normal incr backup run weekdays.

as i could see from the documentation (v.6,4, ba client, p. 138 ) , we will have in mind that there will be some troubles with expiration. I havent really understood what might be the differences, but assume that Ill stay at the classic way of incr. backup of my data partitions weekdays.

Did you get the impacts of expiration between incr-by-date image ?

regards

Marcus

[GIBIN]

i think some of the impacts of incr-by-date backups on expiration are mentioned here:

1. Unlike incremental backups, incremental-by-date backups do not expire deleted files or rebind backup versions to a new management class if you change the management class.

2. if file gets renamed it will not be backed up

Files that were renamed after the last incremental backup, but otherwise remain unchanged, will not be backed up. Renaming a file does not change the modification date and time of the file. However, renaming a file does change the modification date of the directory in which it is located. In this case, the directory is backed up, but not the files it contains.

3.If you perform an incremental-by-date backup on only part of a file system, the server does not update the date of the last full incremental backup. In this case, the next incremental-by-date backup will back up these files again.

[MKoehlerRoss]

thanks for your quick reply.

I could see the situation with renaming the files during my tests. So I have no trust in these kind of backups. It wont be useful for me. Instead of incr-img-by-date I will try out journaling with multiple JBBs on a volume.

Its a pity because we all need to have better strategies on handling large windows volumes without using hardware snapshot provider or things like that.

Thanks for the information.