Restoring An Image Backup To A Larger Disk

Well just the other day my group was asked to help the NT System Admins with the combination of two large disks into one. Both of the disks have been performing image backups so we decided that the largest image would be restored first then the second drive would be restored to the new disk normally. To combine the disks the SA’s made one huge partition (400+ GB) and an SA on my team started the image restore. The following warning was issued when the image was initiated:

***************************** WARNING ********************************
The destination volume is larger than the source volume.  This will reduce the file system '\\machinename\x$' size to '    xxx.xx MB'.
Do you wish to continue? (Yes (Y)/No (N))

This was due to the target disk being larger than the image. We figured the image would not affect the space unused but we were wrong. After the image was restored explorer saw the disk as the size of the image backup but the Windows Disk Management tool saw it as the 400+ GB it was. So the problem was how to recover the disk.  Here is what MS support instructed and the problem was resolved.

When doing an image restore:

If the destination volume is larger than the source, after the restore operation you will lose the difference between the sizes. If the destination volume is located on a dynamic disk the lost space can be recovered by increasing the size of the volume. This will also increase the size of the restored volume.

We also have the following knowledge base doc:

When a Tivoli Storage Manager (TSM) image restore is performed to a target volume that is larger in size than the original volume (from which the image backup was taken), TSM will concatenate the target volume down to the original volume size.  However, within Windows Disk Management (within the Administrative Tools -> Computer Management utility), the disk will appear to still exist as the original larger volume size, even though Windows Explorer will show that the real volume size is now smaller.  In essence, this means that space has been lost, since it is not accessible on the drive and not available for use.  To prevent the loss of this space, the same volume size should be used on the target volume as on the original volume.

As far as I know this fix only works if the disk is dynamic (logical) and not a fixed (physical) disk. So the fix was to increase the disk size again to help it see the space again. I don’t think you need to increase it much but once done it resolves the issue. So if you happen to restore an image backup to a larger partition than it originated from just be aware of what you’ll need to do to reclaim your unused space after the restore finishes.

Question On Image Backups

The image backup feature is a wonderful piece that really saves you when restore time is of the essence, but what do you do when SA’s decide to combine two drives into one and want to use TSM to do it? Well we decided to use the image from the larger drive then do a standard restore of the other drive afterwards. Since I have never done this and don’t restore images frequently something I was alerted to was the message from TSM that states that file system would be changed (the drive was now bigger for the combining of the data). Will the image resize the partition? I don’t recall TSM doing that but then again I can’t remember. Anyone who has done a lot of image backups (particularly to larger drives than what the image came from) input would be appreciated.

New TSM Features

For those unaware IBM has added two new items to the TSM portfolio that I think take it a step above in its service offering. The first is Continuous Data Protection for Files. This software add-on will allow for invisible, real-time file replication. Basically the minute you create a new file it is replicated in a backup location. The following features are available for replication:

• A copy is stored locally


• A copy can be saved to a fileserver or NAS


• A copy can be sent to a TSM server

The product does not require TSM and looks to solve a lot of problems with large fileservers. I’ll admit, I want this as soon as it comes available. The one problem I see is who is going to buy the disk required for this?

The second piece I have seen a need for some time is HSM for Windows. Well wait no longer, it’s here! IBM has just announced HSM for Windows. As with other products it allows you to migrate files off of a server when it reaches a certain age but provides for file level granularity, as the file is now a stub linked to the actual file in TSM storage. To learn more about both products you can read up on them here.

NetApp Filer TOC Issue

I thought I would pass along a notice that we have been informed of a problem with TOC file corruption on NetApp filers that have files with dates before Jan. 1, 1970, and after Jan. 19, 2038. Somehow it causes the TOC backup to abend. It also looks like the TOC can be corrupted when the bitfile in which the TOC file is stored is damaged. If this is the case and the corruption is recent it is possible that the TOC is undamaged on the copypool and could possibly be used for the restore. If the TOCs are unavailable then file level restore will need the absolute path to succeed.    

CHKDSK Utility Flaw Explained

I recently was asked about the file system issue with Windows and thought I would be a little more in depth. The file system problem is resolved with the following patches:

MS831375 and MS873437 for Windows 2000

Here is a good description of the problem (3rd paragraph down) and Microsoft’s page.

http://www.windowsitpro.com/Article/ArticleID/41569/41569.html

http://support.microsoft.com/?kbid=831375

Basically when a large volume has over 4,194,303 files a flaw in the chkdsk utility run in fix mode or repair mode can strip the permissions from the files. Patch MS873437 is related. Here is the link.

http://support.microsoft.com/default.aspx?scid=kb;en-us;873437

MS831374 is for Windows 2003 and is the same issue with the chkdsk utility.

http://support.microsoft.com/default.aspx?scid=kb;en-us;831374

According to our administrators we had systems on other patch reboots go into the chkdsk utility and automatically start running in fix or repair mode. So in our case it was not something that was user initiated. Hope this helps and have fun patching!

Web Interface And The ISC

I recently was informed that the LTO3 format setting was never added to the old web interface. Is this true? I guess you can use the command line or ISC but was a little saddened to hear there was so update for that. What can I expect, they are trying to get rid of the interface. Does anyone know why the DRM feature was/is not in the ISC interface?

Oracle RMAN Catalogue Cleanup

Why do people love Oracle? When I hear mention of Oracle I think of Luke Skywalker when he saw the Millenium Falcon, "What a piece of junk!" Like the Falcon it looks clunky, breaks down easily, and has the most tempermental behavior. When it's running, however, it screams. The problem is that the RMAN catalogue sometimes doesn't do appropriate cleanup. If you want to make sure that a particular node is performing cleanup within TSM run the following select command -

select object_id from backups where node_name= and
backup_date < '2005-07-01 00:00:00'

This can be redirected to a file then used later to delete with an undocumented delete command. I will give the delete command out to those who need it, but remember any deletion from the TSM DB is done AT YOUR OWN RISK! It's unsupported because Tivoli doesn't trust you to not screw stuff up, and although I don't think you will, it's better safe then sorry.