STSADM does two types of backups; site collection and "catastrophic."
You can likely restore either, but the directions are radically
different. Here's a quick overview,
technet.microsoft.com/en-us/library/cc263441.aspx

If you have a bunch of "SPBR" folders and an "spbrtoc.xml" file you've
got catastrophic backups. If you have a single file or a file for each
site collection you probably have site collection backups. Let us know
which type you have and we can tell you about restoring them.

Looks like i have the disaster  ones

To answer your original burning question, no. From a strictly anecdotal
point of view, I have restored to machines of different names on many
occasions.

Not to kick you while you are down but once you get this all settle, I would
look long and hard at a better backup/recovery solution than the built in STSADM
functionality. It is just way to unreliable. Most clients I work with we will
have a multilayered solution consisting of a 3rd party solution (Quest, DocAve,
etc), and Content DB backups  to ensure we can always recover our content. On the
plus side, having a failure like you describe is usually a good example for a
business case in gettiing the purse strings opened by management and getting
some cash for a reliable DR toolset and policy.

I thought you couldn't access the content DBs directly when WSS is using the
built in MSDEE database included in SBS2008 ? At least I tried to get access to
it previously and was told that its not possible, hence why we use stsadm.

Are you suggesting that WSS on anything other than a proper MS SQL install isn't
going to be easily backed up ?

In the SPBR folders you will see a bunch of .BAK files. Those are all of
the individual things STSADM backed up. Your content databases are
included in that. If the BAK containing your ContentDBs isn't obvious by
size, you can open up the XML file in that directory and search for the
name of your DB. That entry will tell you the corresponding .BAK file.
That .BAK file is simply an SQL backup of your database, so it can be
restored directly into SQL without any SharePoint tools. Once you've
done that attach it to the correct web application. As long as all your
versions are right, all your managed paths are right, and all your
Solutions are installed, you should be good to go.

I meant to say stsadm of course.