An option to rename the existing db instead of overwriting it might bevery nice, provided it would deal automatically with the required filename changes (can't have two DBs using the same filenames). (So of course would any other way of rolling back restore, prob=vided you could still do it a while after the restore was finished rather than not just until then).

We did something like that when rolling out upgrades (of databases that were read only on customer sites) using DTS (to copy whole databases), and it's clearly applicable in the restore case too. As DTS over a slow internet connection (which some of our customers had) was slow (and even over a fast connection was sufficiently slow to cause noticeable downtime) we always had DTS create a new DB; this also eliminated the possibility of DTS leaving a partly overwritten live DB as the result of a network or other failure. When DTS completed without errors, we would drop the current back copy, rename the current live DB to be the new back copy db, and rename the new db to be the current live db. If we later discovered that someone had dropped a cog and the new live database was not acceptable we could get thinks back up again in a very short time by renaming the live db back to the new db name and renaming the back copy to the live name.

Another point: having restore automatically destry the old db is the restore completed cleanly would be much less valuable than keeping the old DB (in renamed form) for a while, until someone decides it's no longer needed in case of something nasty coming to light.

Unfortunately I can't see any way of making this usable for really big databases.