Yes. We do this every week by deleting and restoring  our portal using
production data. We use SQL backups exclusively.

We do it as well with SharePoint Backup and Restore tool on the server - no
issues, just copy the production backup files over to the dev  box and use
the same tool to restore.

Which backups are you referring too? I have tried doing this using
the sharepoint portal backup tool and it would not let me restore.
I have also tried using the stsadm backup to no avail. I have heard
to utilize either of those options you need an exact mirror of
production in dev  including the server names. If you could please
describe in greater detail how you accomplished this.

To the person who does this via a database restore:
When you delete the database from dev and restore the production
from production are you using a DTS package? Are you just restoring
the _site database?

I can answer both questions for you;

To use the SharePoint Backup and Restore utility, your systems have to
mirror each other. If they do, simply copy the backup files to the other
sever, start the same utility, and restore the Portal.

stsadm is not a Portal backup solution.

To restore the Portal to an environment  that differs from production, all
you need are the _SITE, _SERV, and _PROF databases. You can use any tool you
like to make a SQL backup. Once the databases are backed up, restore them to
the development  server. You can do all of this through Enterprise
Manager. NOTE: Do not restore the config db, it will cause your restore to
fail!!!!
When you have the db's in place, go to Central Admin and select the Restore
Portal option. Then, just follow along and point to the restored databases;
all your Portal info is stored in those 3 databases ... it's environment
agnostic at that point.

So is there a way to automate what you just suggested? I mean I
know you can write DTS packages for the copying of the databases but
what about the restore portal options? Or do you not need to do
that after the first time?

It's a manual process (or at least I have never tried to automate it) as you
have to enter resource account information each time the Portal is restored
from databases - but, it only takes about 5 minutes and you're done!

I think there might be a command to set that stuff via the command
line if I am not mistaken using stsadmin. One more question. I had
actually done just about everything we have talked about here but I
could not get the DTS package to authenticate between the two sql
servers that are in different domains. I know that someone who is
familiar with network security could probably easy fix an issue like
this. Any suggestions to allow a network account that is in another
domain admin priveledges on a sql server in another domain? It has
been a few months since I worked on this and dont remember all of
the issues i had.

I'll let someone else speak to this issue - I try to leave all those issues
to the DBA.

Double-Take is nice solution for this
This is we are using for DR site failover of portal it mirroring everithing
from Production server to DR server.

By network account do you mean a domain account or do you mean the built in
network account ?

We are also using DoubleTake for our DR site.