This issue occurs if the computer that is running Windows SharePoint Services has insufficient free disk space that is available to host the restored Windows SharePoint Services Web site. This issue may also occur if the Windows SharePoint Services database has reached its maximum allowed size.
Scenario 1 Solution) To resolve this issue, make sure that the computer that hosts the Windows SharePoint Services Web site has sufficient free disk space that is available before you restore the Windows SharePoint Services Web site. When backing up or restoring large site collections make sure that the site collection is set to "no access" if it exists already. Whether the site collection exists or not the -overwrite parameter can be used to bypass conflicts. stsadm -o restore -url
Scenario 2) The site collections listing page will give a clue.The site you were trying to restore was already listed there but when you tried to load it the site didn't work.
Scenario 2 Solution) •Detach and Reattach each of the content db's , this removed the site collection listing from CA but the error still occurred
•Run stsadm -o databaserepair against the database's and it removed a bunch of orphaned records.
Scenario 3) There is tonnes of disk space (20 GB free for the restore of a 3 GB site collection) and tried again. It died with the same error. You run the following query in the SQL Server Management Studio:
SELECT SERVERPROPERTY('productversion'), SERVERPROPERTY ('productlevel'), SERVERPROPERTY ('edition')
As it turns out, the database server was trying to restore the site collection into was running SQL Server Express Edition had a file size cap of 4 GB. When this "farm" was set up, it was done so with a Basic install which by defaul installs SQL Express and inherits it's limitations. The site collection that was used was trying to restore broke the 4 GB limit and as a result the stsadm tool thought there wasn't any disk space available, when really there was a bunch to be had.
Scenario 3 Solution) Upgrading SQL Server Express to Developer/Standard/Workstation/Enterprise -
As a result upgrade the OFFICESERVERS instance of SQL Server running on that machine from Express to Developer (you can upgrade it to Developer/Standard/Workstation/Enterprise, whatever you have in terms of media/licensing). This ends up being pretty easy, you simply find the media/installer and run the setup.exe that you normally would but with an added argument of SKUUPGRADE=1.
When the install wizard gives you get a chance, select the OfficeServers instance and upgrade the database engine. If you want a more detailed walkthrough, one is available here. When you're done, run the same SQL query above and the product edition should no longer be Express. After that small adventure, the restore will work like a charm.
Scenario 4) A lot of transactions in the ULS Logs and SQL Server Logs are growing out of control during the restore process that appear to interrupt the restore, especially if its a very large one.
Scenario 4 Solution) Try the following:
1. Stop IIS
2. Perform the Restore
3. Restart IIS
Basically you are preventing any SharePoint transaction from taking place while you perform the restore.
Scenario 5) Restore runs super slow (for example 6 hrs for a restore of 7 GB backup file) and right at the end throws the "insufficient space" error.
Scenario 5 Solution) Try the following:
1) Delete the Web Application (incl. content database) (OPTIONAL STEP IF YOU ARE OK TO DELETE - MAKE SURE YOU HAVE A DATABASE BACKUP AND STSADM FULL SITE COLLECTION BACKUP)
2) Truncate content database transaction logs in SQL Server
3) Turn Mirroring off on all databases on the SQL Server
4) Ensure that the account performing restore has dbowner and dbcreator permissions