image backup on disk

[dudharkar chandra]

I have observed that one disk is badly fragmented hence I want to take image backup on new disk and make new disk online.
So while initializing new disk with same attribute what I should keep the cluster size.

Original disk is dga106 with has cluster size =48 and size 20GB
New disk would be dga201 20 GB.

Can I use this command
init $1$dga201/cluster_size=48

[John Harper (Barbour)]

init/cluster_size=n has always worked for me.

John

[Ian Miller.]

$ INIT $1$DGA201/CLUSTER=48 etc
the destination disk to be what you want then
$ BACKUP/IMAGE ... $1$DGA201:/NOINIT

to keep the settings specified in the INIT command.

[Jan van den Ende]

dudharkar chandra,

>>>
Original disk is dga106 with has cluster size =48 and size 20GB
New disk would be dga201 20 GB.

Can I use this command
init $1$dga201/cluster_size=48
<<<

Use the previous given:
-- init/cluster
-- backup/noinit

... and do some "preparing for the future

Nowadays you CAN grow your SAN disk on-the-fly, IF you prepare.

add /LIMIT= to the INIT command.
VMS 7.3-2 will allow up to 1 TB, 8.4 (8.3 + patches) up to 2 TB.

Do it now. It will in no way hurt, but it can be a great future bebefit.

hth

Proost.

Have one on me.

jpe

[Shriniketan Bhagwat]

Hi,

>>So while initializing new disk with same attribute what I should keep the cluster size.

During the image restore, BACKUP initializes the destination disk with the attributes of either the source disk or the destination disk, using /INIT and /NOINIT qualifier in the BACKUP command. /INIT qualifier initializes the destination disk with the attributes of the source disk (including the cluster size). By default /INIT qualifier is selected during the image restore. Hence you need not to initialize the new disk (i.e. destination disk) before image restore. You can verify the same by executing $ show dev/full command of both source and destination disk before and after the image restore.

Regards,
Ketan

[Hoff]

You might want to figure out why the disk is getting fragmented lest the server and the storage get itself back into the same predicament.

Bumping your cluster factor does mean fewer hunks of storage which inherently lowers the fragmentation, but I'd wonder if this fragmentation isn't caused by access contention and too little space on the disk. (A 20 GB disk is small.)

Bumping your cluster factor on a disk with a gazillion files also uses up some of your storage capacity; on average, you're wasting half the cluster factor times the number of files on the disk.

If you're perpetually running with application contention or with disks that are very nearly at capacity (anything past about 80% or so tends to fragment), the adjusting the cluster factor via an INITIALIZE and specifying BACKUP /NOINIT on the restore probably won't help appreciably with the underlying problem.

Go get some storage. Get larger disk units. And get more disks.

Slice up these storage units by applications that write temporary and log and trash files, disk(s) for production database stuff, and generally avoid having multiple applications incrementally extending multiple files on one disk. Get yourself more than one 20 GB disk, in other words. And spread your activities across the spindles.

While you might slice and dice storage off your fibre channel controller, make sure you have enough storage and enough units.

On the disks, set your extent sizes appropriately for the applications and the processes. (This is an alternative to larger cluster factors, and it serves to avoid fragmentation when you're working with files that are multiples of the cluster factor.)

I'd suggest cluster factors that are a multiple of 16 blocks, too.

And in addition to the volume and process and application and system extent-size settings, also have a look at whether a defragger might be appropriate.