Solaris

If you're going to provide the path to the dump archive to ufsrestore you need to tell it with the 'f' switch (which says the next field on the command line is where the dump file is).

For example:

Code:

# ufsrestore xf <dump file path>

in your case the dumpfile path will be /mnt/<whatever>.

or

Code:

 
 # ufsrestore tf <dump file path>

to list a dumpfile.

You should be able to 'cd /mnt' and then list files to check it's there okay. Then change to /a where you want to files restored to and just empty the whole dump into this directory (/a).

So yes, if you want to put the dump path on the ufsrestore command line you need to use the 'f' switch.

Have you ever seen an error like this before?

Code:

# ufsrestore tf /mnt/partition0.dmp
resync restore, skipped 265154 blocks
Cannot find file dump list

# ufsrestore xf /mnt/partition0.dmp
resync restore, skipped 265154 blocks
Cannot find file dump list

Code:

# ufsrestore xf /mnt/usr/home/partition0.dmp
resync restore, skipped 265154 blocks
Cannot find file dump list

Off the top of my head, no, don't recall seeing that error. My money would be on a blocking factor issue. Firstly, I'd be inclined to try to list the dump using different blocking factors (since we don't know, or have the script that wrote out the dump file).

Use the 'b' switch to specify blocking factor and see if you can get an error free clean listing.

For example:

# ufsrestore tbf 512 /mnt/<whatever>

Try values of 512, 1024, 2048, 4096, 10240 and any other multiple of 512 you can think of.

Note: In above example putting the 'b' before the 'f' means blocking factor in first field and dumpfile path in the second field. You could swap them around if you want. Hope I've explained that okay.

Post back if any of that works. Until you can get a clean listing I wouldn't try the restore 'x' option.

---------- Post updated 25-08-16 at 09:30 AM ---------- Previous update was 24-08-16 at 07:07 PM ----------

In terms of the files they gave you it would be worth using tar to extract the SPACE.TAR to see what is contains. You can do that from single user mode. It might contain useful information about disk layout.

In terms of the .dmp files you have a partition0 and a partition3. In small solaris systems with one physical drive the vtoc is typically:

slice0 boot partition (O/S)
slice1 swap space (you need to configure some)
slice2 represents the whole drive and is not edited
slice3 first non-root partition (perhaps /u)

So the two files you have being 0 and 3 make perfect sense.

What we don't know is what the .vtoc files really are. As we agree they are too big to just contain the vtoc which would be just a few dozen bytes. So let's leave those for now.

If we are able to restore the root partition then we can get our hands on /etc/vfstab which will tell us what filesystems get mounted when the system boots. We can also have a poke about to see if we can find the script that did the backups.

Q: Are you attempting to restore the system onto new disk(s) on the same hardware? Or is it different hardware? If it's the later there will be more things to do to get the system on its feet.

Thanks again for your continued help.

I tried to list the files by changing the blocking factor all the way up to 81920. For some reason it cannot find the file dump list.

Code:

# cd /mnt/
# ls
bin             etc             lost+found      platform        usbdrive
cdrom           export          mnt             proc            usr
data            home            net             sbin            var
dev             kernel          opt             space           vol
devices         lib             partition0.dmp  tmp             xfn
# ufsrestore tbf 512 /mnt/partition0.dmp
resync restore, skipped 265154 blocks
Cannot find file dump list
# ufsrestore tbf 1025 /mnt/partition0.dmp
Block size must be a positive, even integer
# ufsrestore tbf 1024 /mnt/partition0.dmp
resync restore, skipped 265154 blocks
Cannot find file dump list
# ufsrestore tbf 2048 /mnt/partition0.dmp
resync restore, skipped 265154 blocks
Cannot find file dump list
# ufsrestore tbf 4096 /mnt/partition0.dmp
resync restore, skipped 265154 blocks
Cannot find file dump list
# ufsrestore tbf 10240 /mnt/partition0.dmp
resync restore, skipped 265154 blocks
Cannot find file dump list
# ufsresore tbf 81920 /mnt/partition0.dmp
ufsresore: not found
# ufsrestore tbf 81920 /mnt/partition0/dmp
/mnt/partition0/dmp: No such file or directory
# ufsrestore tbf 81920 /mnt/partition0.dmp
resync restore, skipped 265154 blocks
Cannot find file dump list

I tried to extract the space.tar file and I got a read-only file system error. I used chmod to make everything a+w+x, but I have had that error before when booting from the CDROM in single user mode. I'm going to reboot from the HDD and extract it. I extracted it before with no issues, but I think I have since wiped that drive.

I am attempting to restore the system onto new disks on new hardware. The new hardware is supposed to be identical make/model/etc to the old. I'll post an update when I reboot and get the .tar extracted.

---------- Post updated at 09:44 AM ---------- Previous update was at 09:17 AM ----------

I extracted space.tar and it only extracted files into /space and subdirectories below it. They were user profiles/data files for the 3rd party software the server runs. Unfortunately, nothing went directly into the root directory or /etc/init.d. There was also nothing that looked like an installation/backup/.sh/ script. I'm going to give ufsrestore tbf another shot now that I'm out of read only mode.

Hmmmmmm.......not being able to ufsrestore partition0 is a bit of a show stopper.

I've been looking at the file sizes that you posted again and coming to the conclusion that your .vtoc files are in fact probably archive files (dump table-of-contents) created by using the 'a' switch on the ufsdump command. If so, these should have the suffix .dtoc in my book. Mis-named by the previous sysadmin perhaps. Such files are used by ufsrestore to determine whether a file is, or is not, in a dumpfile when the restore of one file is requested (not the whole filesystem).

So how did you come by the .dmp files? Is there anyway that they could have been corrupted? Have they been ftp'd or otherwise copied from another system? Could they have been written to tape originally and subsequently 'dd' off to disk? If so, the blocking factor could be a very low number like 10.

On you post you didn't show that you tried other blocking factors like 8192, 3072, 20480 and the like. Although unlikely, any multiple of 1024 could just work.

Sorry for the delayed reply. Another system failed yesterday, but at least I knew how to fix that one hahaha.

I tried every blocking factor from 512 to 10240 in 512 increments. I also tried the following ones.
1 2 4 8 10 16 32 64 128 256 512
1024 2048 4096 8192 16384 32768 65536 131072 262144 524288 1048576 2097152 4194304 8388608 16777216 33554432 67108864 (I ran out of buffer on the last one).

The server won't boot with the graphics card installed, so I am using putty to serial into the server. That means I cant use the up/dwn arrows to auto fill the line or back and forward to edit it. I have to hand jam each command over and over. If I had more time, I'd try every factor possible.

I am working on getting in contact with the person who backed up the system. They are not local and rarely have cell phone coverage. I'm starting to think I should just hammer down on getting ahold of him to find out exactly what he did.

The files I am trying to restore from haven't been Ftp'd. They were on the "new" systems HDD when I received it. I did FTP them off though because I wanted to have multiple backups. I haven't tried to restore from the Ftp'd copies yet.

Have you tried to list the contents of partition3.dmp? This may tell us whether both .dmp files suffer from the same problem or whether you can successfully read partition3.dmp.