Take the 2-minute tour ×
SharePoint Stack Exchange is a question and answer site for SharePoint enthusiasts. It's 100% free, no registration required.

I am moving a site from one url to another within the same site collection.

  1. Stsadm -o backup..... works great and says the operation completed successfully
  2. since the guid's of everything stay the same during a backup... i deleted the orginal site. Operation competed successfully
  3. Mind you this is production
  4. stsadm -o restore Now I restore to another url location... whoops i get a Write error on file "wssxxxxxxxxxxx_1.tmp". Lovely
  5. Now i can't put it back. Looking at having to get the collection from the database backup. Is there a way to get it back any other way?
share|improve this question
add comment

3 Answers

up vote 1 down vote accepted

So after investigating, I saw that others where having a similar issue with large sites.. 15+ GB. Now... my site only tops out at 1GB or so. There shouldn't be a problem right? Well if you consider that the underlying problem could be the actual room left on the physical drive you get closer to the issue here. With some IT outfits servers are deployed with a dinky C drive/partition for the os and a much bigger D drive/partition for 'Data'.

This setup does not work for SharePoint. Yell at your IT colleges if need be. There are some things that can be sloughed off to the d drive, but a lot of stuff happens on the C drive that you don't have control over. One of these is where SharePoint puts the temp file is uses during restoration. You guessed it the C drive. In addition it just makes sence not to have to move everything to the Data area for no reason. (If someone can tell me why people do this... it would be great.)

If that drive is fragmented and is down to it's last 100 MB or so stsadm will not be able to complete building whatever is in the temp file.

The answer here is to make sure that you have enough room for that temp file to be created. A good rule of thumb that I go by is that no partition should have less then 15% free disk space. This was a good rule in previous Windows OS's and I'm sticking to it.

share|improve this answer
add comment

I'm not sure that you have used the right method here. Stsadm -o backup will back up your entire site collection, not a subweb only. So, if you have backed up using this method and are attempting to restore the backup to another url within the site collection you have just backed up, it will fail. This is because it is trying to restore the entire site collection. You need to restore your backup to a new web application, or restore a database backup to restore the missing subweb. Then, once you have your subweb, you can use stsadm -o export and import to move it within the existing site collection.

Lori

share|improve this answer
    
When I say site I mean a site collection. With restore you may restore you site collection to the same web application/content database as long as you remove the orginating site beforehand. The reason for this is that backup/restore keeps the GUID's intact. Failure of removing the orginal site will cause SharePoint to complain. Duplicate GUID's are a no no. –  Mike T Nov 13 '09 at 19:26
add comment

Create a new content database with central admin your web app.

Create a managed path with your cental admin (explicit inclusion path)

restore with stsadm and use your new managed path like URL.

Dan

http://www.dannybrabant.com

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.