Niall,
When changing cluster size, in addition to /noinit I also recommend using /truncate.
This tells backup to use the "used" size when allocating space for the new file, which will be rounded up to the next cluster. The default behavior is to use the allocated size of the source file to determine the initial output size, which is then rounded up to the next cluster.
If you don't do this, you will get the non-intuitive result that the output disk will have less available space than the original disk.
In other words if you have a disk with a current cluster size of 17, and you want to reinitialize it with a cluster size of 8, if you do not use /truncate, all the (non-zero length) files will be created with an allocation of at least 24 (the next multiple of 8 .ge. 17).
This is one reason I like to always initialize my disks with a cluster size that is a power of 2, (1,2,4,8,16,32...). If both the source and destination disks have power of 2 cluster sizes, then the size of a file will never grow when backing up to a device with a smaller cluster size, even if you don't use /truncate. This is because the source disk with the larger cluster size will always have a cluster size that is an integral multiple of the destination disk.
I almost always use /ignore=nobackup as well. This takes a bit more time backing up "junk" like the page file, but it will preserve your SYS$ERRLOG.DMP and SYSDUMP.DMP contents, as well as any LD .DSK files that are marked /nobackup. If you don't use /ignore=nobackup, the files will be recreated but with undefined contents; the contents won't be copied unless you either set them /backup or use /ignore=nobackup.
Note that if you are using a saveset as an intermediated step, the backup command creating the saveset must use the /ignore=nobackup. Some testing I just did on Alpha 8.3 shows that the contents in the saveset are always restored, i.e. /ignore=nobackup does not seem to be required when restoring files from a saveset that was created with /ignore=nobackup.
DFU is useful to determine what files are set /nobackup. You can then determine if it is appropriate to use /ignore=nobackup
$ define/job dfu$nosmg 1 ! don't use screen management option
$ dfu search /characteristic=nobackup /sort sys$sysdevice
In summary:
$ ! if you have dfu installed, I recommend creating a report, which will show a lot of info from the home block
$ dfu report
I highly recommend doing (at least) the next parts when booted from a disk other than the src_disk, i.e. an 8.3 installation disk, or another bootable drive (preferably with at least 8.3 loaded)
I really recommend against restoring over your existing system disk. That is inherently risky. Much better to restore to a new drive; if that is the case, then why not just do a disk-to-disk image backup? The below assumes you are using two disks, and booting from a third disk (can be the 8.3 installation CD) Things in square brackets [ ] are optional.
$ init /cluster= [/limit /system /erase=init] ... ! see stuff from DFU report /header= /own /user etc.
$ mou/for
$ analyze/disk/repair
$ backup/image/noinitialize/truncate [/ignore=nobackup]
$ dismount
$ mount/ov=id
$ analyze/disk/repair
$ dism
Boot from . If SAN disk, you will need to use wwidmgr to make the new disk available for SRM booting. This assumes Alpha.
Note: if you are using something less than 8.3, then the /limit stuff will be lost as backup didn't know what to do. /NOINIT really means "use existing values when reinitializing the disk", and pre-8.3 backup didn't know about /limit.
Jon
it depends
