Can ufsdump create files that have a .vtoc and .dmp extension?

Hello,

I was handed the job of restoring a drive on a old Sun Micro server running Solaris 8. The person who created the backup files told me I would need to use UFSrestore to restore the drive. I have read about everything on ufsrestore that is on this forum and have a decent grasp on how it works, but I still haven't had any luck restoring the drive.

I created my own ufsdump of an unimportant directory and restored it to just to make sure I wasn't missing anything. One thing that I noticed is that ufsdump stored the directory as a singular file with a .ufs extension. The files I was given have multiple files for each partition. Is a list of the files they gave me.

SPACE.TAR        partition0.vtoc  partition3.vtoc
partition0.dmp   partition3.dmp

I understand that the .tar file is just a compressed group of file and directories that is completely separate. Is it possible for ufsrestore to have .vtoc and .dmp extensions? If not, does anyone know of a tool that might be used to create backups with these extensions?

Thank you!
Curt

Note:
ufsdump -
man pages section 4: File Formats

There is magic in the headers, i.e. the file command will tell you if a file is in usable ufsdump format, regardless of any file extension.

Try that to identify your files. Ignore file extensions for now.

I would expect that the .dmp files are ufsdump files and the .vtoc files are backups of the partition tables (vtoc=virtual table of contents).

Any sysadmin knows that if a drive fails, not only do you need the data (backup) but also the partition layout of the drive. Otherwise you have to guess the partition size(s), then you get them wrong, and the restore operation fills up the filesystem.

There is only one vtoc per physical drive. How many physical drives are there in the system?

If you look at the sizes of the files I would think the .dmp files are the actual backup and therefore maybe large (depending on how much data was on the filesystem) and the .vtoc files very small and readable with 'cat'.

The sysadmin might well have created a script which read the vtoc and wrote it out to a file (.vtoc) and then snapshot the filesystem (fssnap), and then dumped it (ufsdump). So although ufsdump does not create files containing the vtoc a script could be used to do that all in one go.

Jim and Hickd8,

Thanks for taking the time to reply. I have continued to work on it with no success.

Jim- Thanks for the tip about the file command. You were correct and the .dmp files are in ufs dump format.

 # file partition0.dmp
partition0.dmp: ufsdump archive file

It helps to know that I'm at least on the right road.

Hicksd8- I think you are correct about the .vtoc files being the partitions table of contents. They are smaller, but not as small as I expected.

# ls -l
total 13969424
-rwxr-xr-x   1 root     root     2795765760 Jan 29 17:34 *
-rwxr-xr-x   1 root     other    3095059086 Jan 28 02:18 partition0.dmp
-rwxr-xr-x   1 root     other    12546538 Jan 28 02:18 partition0.vtoc
-rwxr-xr-x   1 root     other    1343487 Jan 28 02:18 partition3.dmp
-rwxr-xr-x   1 root     other    1341439 Jan 28 02:18 partition3.vtoc
-rwxr-xr-x   1 root     other    1242731825 Jan 28 02:19 space.tar

Don't pay attention to the dates, I'm booted from a cdrom copy of solaris 8 in single user mode at the moment.

I have two drives in the system I am working on, but I can only guess there were two drives in the other server that crashed. Unfortunately, I wasn't there when it happened, and they had already gotten rid of the old hardware.
I tried to use the cat command to read the .vtoc file but it just spit out a bunch of junk.

a8none//dev/dsk/c1t0d0s0ncciris???_~

Thanks for the tips, but so far I haven't had much luck getting ufsrestore to work on the .dmp files.

I'll update today as I try again with the exact commands I'm using. I am by no means a sysadmin, so there is a great possibility I'm doing things wrong.

Curt,

---------- Post updated at 10:58 AM ---------- Previous update was at 08:27 AM ----------

These are the instructions I am currently working from. -removed link for lack of posts-

I'm not sure if the forum will allow outside links, do I'll go through step by step what I am doing and why I am modifying parts.

Step 1. Boot server from cdrom in single user mode.

boot cdrom -s

Step 2. Create a partition for the drive I am trying to restore to. Side note: I have already repartitioned the drive and created a new file system on it.

mkdir /tmp/slice0

Step 3. Mount the drive to that directory.

]mount /dev/dsk/c1t1d0s0 /tmp/slice0

Step 4. Next I am mounting a second hard drive on the system with the backup files in it to restore from. Side note: I tried to do this from a thumb drive and recieved an error. I also burned the backup files to a cd, but solaris 8 will not read them. I also tried to burn it from multiple computers like other help forums suggested to no avail.

mkdir /tmp/backup
mount /dev/dsk/c1t0d0s0 /tmp/backup

Both devices mounted successfully.

/tmp/slice0 on /dev/dsk/c1t1d0s0 read/write/setuid/intr/largefiles/onerror=panic/dev=800008 on Tue Jan 30 11:43:54 1996
/tmp/backup on /dev/dsk/c1t0d0s0 read/write/setuid/intr/largefiles/onerror=panic/dev=800000 on Tue Jan 30 11:48:06 1996

Step 5 Execute the ufsrestore command. I may be doing this wrong because I dont really understand what the individual parts of the pipeline function are doing.

# ufsdump 0f - /tmp/backup/partition0.dmp | (cd /tmp/slice0;ufsrestore xvf -)

Output:

# ufsdump 0f - /tmp/backup/partition0.dmp | (cd /tmp/slice0;ufsrestore xvf -)
DUMP: Writing 32 Kilobyte records
DUMP: Date of this level 0 dump: Tue Jan 30 11:53:04 1996
DUMP: Date of last level 0 dump: the epoch
DUMP: Dumping /dev/rdsk/c1t0d0s0 (:/tmp/backup) to standard output.
Verify volume and initialize maps
DUMP: Mapping (Pass I) [regular files]
DUMP: Mapping (Pass II) [directories]
DUMP: Estimated 6060298 blocks (2959.13MB).
DUMP: Dumping (Pass III) [directories]
Dump date: Tue Jan 30 11:53:04 1996
Dumped from: the epoch
DUMP: Dumping (Pass IV) [regular files]
Extract directories from tape
Initialize symbol table.
Extract requested files
extract file ./partition0.dmp

DUMP: 46.50% done, finished in 0:11
DUMP: 92.99% done, finished in 0:01
DUMP: 6060286 blocks (2959.12MB) on 1 volume at 2347 KB/sec
DUMP: DUMP IS DONE
Add links
Set directory mode, owner, and times.
set owner/mode for '.'? [yn] set owner/mode for '.'? [yn] y

As you can see below it just created another dump file in the root directory. The /usr is from where I tried to do this yesterday and it kept the directory structure the dump file came from which was /usr/home. It didnt unpack those files either, just created a dump file there.

cd /tmp/slice0
# ls -l
total 6048034
drwx------ 2 root root 8192 Jan 29 07:49 lost+found
-rwxr-xr-x 1 root root 3095059086 Jan 29 18:05 partition0.dmp
drwxr-xr-x 3 root sys 512 Jan 28 02:15 usr

I think I am creating a dump instead of restoring one.

---------- Post updated at 12:15 PM ---------- Previous update was at 10:58 AM ----------

I went ahead and tried to restore the .dmp file that is on the target HDD just to see what would happen. Below is the error I have gotten when trying to restore it in the past from the target disk.

# cd /tmp/slice0
# ls
lost+found      partition0.dmp  usr
# ufsrestore rf partition0.dmp
resync restore, skipped 265154 blocks
Cannot find file dump list

You are demonstrating some knowledge here but it's difficult for us to judge whether you know the steps to take. Therefore, at a risk of telling you stuff you already know (for which I apologise) I'm going to start from ground zero on a disaster recovery of Solaris 8 using new hard drives.

Firstly though, if you boot into single user as you did, you should be able to verify the .dmp files as proper ufs dumps by using just the ufsrestore command with the t option. This should output a list of files in the archive(s).

Now, if you're working with brand new hard drives, if now already labelled, you will need to write Sun label. You will probably need to invoke the format command in expert mode to do that:

# format -e

The next step will be to write a vtoc (otherwise known as a partition table) to the disk. You do that using either 'format' (no expert mode required) to set it manually (long-hand) or 'fmthard' if you had a prior .vtoc file that made sense. Remember that slice 2 shows the capacity of the whole drive which you do NOT changed. Slices must NOT overlap.

Next, now you have a slice that you want to restore a ufsdump to you need to make a filesystem on that slice using:

# newfs <node name> (eg, /dev/dsk/c0t0d0s0)

Next, you now mount that slice on a mount point using the 'mount' command. Changing into that directory you should find only a 'lost+found' directory; nothing else.

Remaining in that directory you then just ufsrestore using the x (extract) option the whole .dmp file into the filesystem you've just mounted.

That's it.

If you are restoring a boot disk then you will also need to write out the 'bootblk'. Search this forum or Google for how to do that (and post back here if you need help).

I hope that helps but, as I say, it's difficult to judge your knowledge level. Just post back here and post your further questions. There's plenty of help available here.

---------- Post updated 24-08-16 at 10:05 AM ---------- Previous update was 23-08-16 at 09:42 PM ----------

This thread might be useful to add more information (as they say "Here's one I made earlier")

Restoring a system from a backup

Also, when booted in single user mode from a DVD, you have two mount points available on the DVD; /a and /mnt

I normally mount the device with the .dmp file (maybe a NFS mount from a remote machine containing the dump) on /mnt
I normally mount the newly created filesystem (slice) on /a

Change directory to /a and ufsrestore the dump.

Hope that helps.

Hi Hicksd8,

Thanks again for all the great info. As far as experience level, I had never worked with Solaris or Unix servers up until last week. What I know is what I've learned from Google and forums the past few days. I've dealt with ubuntu servers quite a bit, but thats a whole different ball game. Feel free to explain it to me like a toddler if you have the time. I could use the help!

I tried ufsresore with the t option and these are the results.

# cd /tmp/backup
# 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 -t partition0.dmp
/dev/rmt/0: No such file or directory
# ufsrestore -t /tmp/backup/partition0.dmp
/dev/rmt/0: No such file or directory
# ufsrestore t /tmp/backup/partition0.dmp
/dev/rmt/0: No such file or directory
# ufsrestore t partition.dmp
/dev/rmt/0: No such file or directory
#

I went ahead and completed the steps you laid out. I mounted the HDD with the backup files at /mnt.

I setup the partitions, labels, and a new file system on the drive I am trying to restore to. I mounted it to /a like you suggested.

Below shows where I'm at.

/mnt on /dev/dsk/c1t0d0s0 read/write/setuid/intr/largefiles/onerror=panic/dev=800000 on Mon Jan  1 11:23:13 1996
/a on /dev/dsk/c1t1d0s0 read/write/setuid/intr/largefiles/onerror=panic/dev=800008 on Mon Jan  1 11:24:36 1996
# 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
# pwd
/mnt
# cd
# cd /a/
# ls
lost+found
# ufsrestore x /mnt/partition0.dmp
/dev/rmt/0: No such file or directory

Everytime I try to use the ufsrestore command I get an error that looks like it cannot find the tape drive /dev/rmt/0. I'm sure I must be putting in the file path wrong or something.

Thanks again for all the great info!

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:

# ufsrestore xf <dump file path>

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

or

 
 # 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?

# 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

# 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.

# 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.

Good suggestion.... I was able to read the file list and there were only one directory in partition3.dmp. It threw an error that partial block read was: 53247 should be 64512. I had the same error when I extracted it. When I tried to see what was in the directory I get an error that the directory doesn't exist.

# ufsrestore xf /a/usr/home/partition3.dmp
partial block read: 53247 should be 64512
abort? [yn] n
You have not read any volumes yet.
Unless you know which volume your file(s) are on you should start
with the last volume and work towards the first.
Specify next volume #: 0
Volume numbers are positive numerics
You have not read any volumes yet.
Unless you know which volume your file(s) are on you should start
with the last volume and work towards the first.
Specify next volume #: 0
Volume numbers are positive numerics
You have not read any volumes yet.
Unless you know which volume your file(s) are on you should start
with the last volume and work towards the first.
Specify next volume #: 1
set owner/mode for '.'? [yn] n
# ls
server     lost+found
# cd server
server: does not exist
# cd /server
/server: does not exist
# ls
server     lost+found
# cd /server
/server: does not exist

Can you do a

ls -l

on that directory to see exactly what the file 'server' is. Perhaps it's a file and not a directory. That will also show its size.

Can you try:

 
 ufsrestore -ivf <dumpfile path>
 

in which i=interactive just to see if that tells us anything. Try it on both (or even all files). You could also add the 'd' switch (d=debug on).
So

 
 ufsrestore -idvf <dumpfile path>
 

I don't have a SPARC system here right now to test so some of that may not work.

---------- Post updated at 05:05 PM ---------- Previous update was at 04:28 PM ----------

In case these files were originally on a tape, you might also try:

ufsrestore tvaf <part0 vtoc file> <part0 dump file>

If I'm right in guessing that your .vtoc files are actually dump-table-of-contents files then that might tell you something.

Nothing to lose so let's try everything.

Well thats cool. I found out the block size is 126.

Partition3.dmp tried to dump on a drive that doesn't exist on this system (c1t0d0s3).

# ls -l
total 18
lrwxrwxrwx   1 root     other         14 Jan  6 09:44 server -> /space/server
drwx------   2 root     root        8192 Jan  1 11:06 lost+found

# ufsrestore -idvf /a/usr/home/partition3.dmp
Verify volume and initialize maps
Media block size is 126
Volume header begins with record 1
Dump   date: Sun Nov 22 11:27:01 2015
Dumped from: the epoch
Level 0 dump of /home on ncciris:/dev/dsk/c1t0d0s3
Label: none
maxino = 4194305
Remove mask header
File continuation header, ino 2
Dump mask header
partial block read: 53247 should be 64512
abort? [yn] n
File continuation header, ino 2
Extract directories from tape
File header, ino 2 at record 21
Initialize symbol table.
got word `/usr/bin/more'

# ufsrestore -idvf /a/usr/home/partition0.dmp
Verify volume and initialize maps
Media block size is 126
Volume header begins with record 1
Dump   date: Sun Nov 22 12:32:33 2015
Dumped from: the epoch
Level 0 dump of / on ncciris:/dev/dsk/c1t0d0s0
Label: none
maxino = 1818625
readhdr fails at 223 blocks
Remove mask header; predicted 222 blocks, got 44169 blocks
File continuation header, ino 18192; predicted 512 blocks, got 221720 blocks
resync restore, skipped 265154 blocks
Cannot find file dump list

# ufsrestore -idvf /a/usr/home/partition0.vtoc
Verify volume and initialize maps
Media block size is 126
Volume header begins with record 1
Dump   date: Sun Nov 22 12:32:33 2015
Dumped from: the epoch
Level 0 dump of /home on ncciris:/dev/dsk/c1t0d0s3
Label: none
maxino = 4194305
Remove mask header
File continuation header, ino 2
Dump mask header
partial block read: 53247 should be 64512
abort? [yn] n
File continuation header, ino 2
Extract directories from tape
File header, ino 2 at record 21
Initialize symbol table.
got word `/usr/bin/more'

# ufsrestore -idvf /a/usr/home/partition0.dmp
Verify volume and initialize maps
Media block size is 126
Volume header begins with record 1
Dump   date: Sun Nov 22 12:32:33 2015
Dumped from: the epoch
Level 0 dump of / on ncciris:/dev/dsk/c1t0d0s0
Label: none
maxino = 1818625
readhdr fails at 223 blocks
Remove mask header; predicted 222 blocks, got 44169 blocks
File continuation header, ino 18192; predicted 512 blocks, got 221720 blocks
resync restore, skipped 265154 blocks
Cannot find file dump list

I'm not sure what it is looking for when I try to dump the .vtoc files. I had to interrupt just to get back to the prompt.

# ufsrestore -idvf /a/usr/home/partition0.vtoc
Verify volume and initialize maps
Media block size is 126
Volume header begins with record 1
Dump   date: Sun Nov 22 12:32:33 2015
Dumped from: the epoch
Level 0 dump of / on ncciris:/dev/dsk/c1t0d0s0
Label: none
maxino = 1818625
readhdr fails at 223 blocks
partial block read: 31210 should be 64512
abort? [yn] n
Mount volume 2
then enter volume name (default: /a/usr/home/partition0.vtoc)
Volume header begins with record 1
Wrong volume (1)
Mount volume 2
then enter volume name (default: /a/usr/home/partition0.vtoc) mount
Cannot open mount
Mount volume 2
then enter volume name (default: mount) /a/usr/home/partition3.vtoc
Volume header begins with record 1
Wrong volume (1)
Mount volume 2
then enter volume name (default: /a/usr/home/partition3.vtoc) /a/usr/home/partition3.dmp
Volume header begins with record 1
Wrong volume (1)
Mount volume 2
then enter volume name (default: /a/usr/home/partition3.dmp) ^Cufsrestore interrupted, continue? [yn] n

I think that a 126 block factor means that the dump was originally sent to a cartridge drive and/or was written to disk in cartridge format (using the 'c' switch). If that's right it begs the question whether there was more than one tape volume for either or both part0 and part3?

Anyway, more things to try with our new found information:

(I'm still going to assume that your .vtoc files are actually dump archives)

 
 ufsrestore tvaf /a/usr/home/partition0.vtoc /a/usr/home/partition0.dmp
  
 ufsrestore tvcaf /a/usr/home/partition0.vtoc /a/usr/home/partition0.dmp
  
 ufsrestore tvbaf 126 /a/usr/home/partition0.vtoc /a/usr/home/partition0.dmp
  
 ufsrestore tvcf /a/usr/home/partition0.dmp
  
 ufsrestore tvbf 126 /a/usr/home/partition0.dmp
 

You could also try all of the above on partition3 stuff.

Hickd8,

I tried all of your recommendations to no avail.I think the backups might be corrupted. I have an alternative solution now that doesn't involve restoring the backup files. I am just going to proceed with that. Again, thank you for all your help and patience.