If you do your backups with smigrate there is no way to avoid  this.
Smigrate will not maintain any user level information like permissions,
owners, etc. The best you can do as an admin is mitigate the damage by
doing the smigrate restore as another user so that their name is
attached to everything.

Is there a backup/restore tool out there that doesn't
do this? I don't even need to retain  permissions- I just need to
keep the "created by" and "modified by" names  the same as they
originally were.

I believe that Smigrate will maintain "Created By" and "Modified By" for
existing items. I looked at some items that I used Smigrate to import
websites into another portal, and the item-level user information was
preserved. However, site-level and list security permissions were lost.

Yes- I just checked older sites where I did this, and they retained
those details as well.

So now my big mystery is simply why this is happening to this one
particular site  of mine. I've tried about 5-6 times now to do a
backup/restore of this site, and each time it wipes out that crucial
user info. I noticed it's actually also wiping out the "assigned to"
folks from the tasks list.

I don't know how to troubleshoot this one. Is it possible that
there's something wrong w/ the site itself?

You may want to try using STSAdm.exe and backup/restore the entire site
collection to see if that information is still preserved.

I've been forced to use Smigrate a few times and every time I've used it
it has wiped out the Created By information. As others have said,
STSADM will maintain this information. The catch is that STSADM will
only work at the site  Collection level, whereas Smigrate will work at
the Subsite (also called Webs) level.

I think when I have used smigrate to migrate within the same site  collection,
the created  by information was preserved. But when I've used smigrate to migrate
from one site collection to another, it does not preserve it. This makes sense
to me, however, since the User IDs are all stored at the site collection level.

I unfortunately don't have server access, so I do the following (not
sure if it's the equivalent to using smigrate/stsadm or not):

-open site  in frontpage
-"tools," "server," "backup website"
-create a new subsite  under another site
-stop at the template picker page and copy URL
-go back to frontpage, "open site" using the URL of the new site I
just created
-"tools," "server," "restore web site" (and I choose the fwp file I
created when backing up the original site)

This is how I've been doing it since I can't go into the server's
command prompt.

Well, I've been testing this today, and all I can think of is that
the site in question  is very very old (created in Feb '04 and hardly
touched since). It hasn't happened w/ any of the newer sites I've
backed up/restored.

You can run smigrate from a workstation, but you must run stsadm from a
SharePoint front-end web server. Smigrate and FrontPage create the same
backup files (*.fwp). I wonder if Smigrate commands preserve more
information than FrontPage (?). I prefer Smigrate because it can be
scripted.

I think you'll find Smigrate and FrontPage backups of the same web will
maintain the same information.

STSADM can be scripted, but like you said, it has to be run on the
server. And it only deals with Site Collections, which is somewhat
limiting.

FrontPage is functionally identical to smigrate. It uses the same
process. FrontPage is essentially just a GUI front end for Smigrate in
this regard.