Tag Info

Hot answers tagged

16

Backing up with SQL Server is a good scenario if you know what the limitations are. Essentially, this only works fine with normal content databases. Backing up the configuration database is possible, but it's not supported to restore it. In case of a disaster, you'll have to build a new farm. This means that detailed documentation is essential. When you ...


11

I'm glad you included an image of the operation in progress, because it makes it easier to clear up some confusion and answer your question. I think previous respondents missed the fact that you're actually working in SharePoint Designer 2007 -- not Central Administration or the command line. First, let me clear up some confusion: the operation you're ...


9

There are lots of point to discuss before coming to a conclusion here. But I will just explain the different possible ways you could do backup in SharePoint in an order of good to best. Central Admin Backup - This is a default UI option that comes within Central Administration. It allows to take full and differential backups. You have the additional ...


8

Actually, that's going to depend on what release and build version of SharePoint you're using. If you have a SharePoint 2007 farm that hasn't yet been patched to Service Pack 2, you're going to have to manually lock the site collection before you back it up, regardless of whether its a Full or Differential backup. (And for goodness sakes, please patch it ...


8

As of now, there is no out of the box facility to backup an entire SharePoint site and restore it to another farm as you do for on premise SharePoint applications. The only option currently available would be to use the "Save site as template" option for sites, which would take a backup of max 50 MB. Visit this blog for more details. You can check out for ...


6

I don't think it was intentional, but this is actually something of a trick question. Let me explain. There are basically two different types of backups that you can perform: farm-level (catastrophic) backups and site collection backups. The former is used to back up components such as the entire farm, a Web application, a content database, etc. The ...


6

You would only need to backup your 14 folder if you made added files or changed files in the 14 folder manually (meaning not through a deployed package). I would, however, make a backup of your web.config files if you have any custom connection strings, app settings, or service bindings.


5

Two options. For site collection administrators you can backup sites (with content as long as it's under 10mb) by saving the site as a site template. The template will be stored in the root site collection and any SC admin can use it to create a new site on another site collection. Not however this doesn't give you full fidelity as several things (namely ...


5

If you've created the blog as a site collection, I would recommend going with STSADM's Backup operation, using the -URL parameter to indicate that you're doing a site collection backup instead of a catastrophic backup. Here's the TechNet article on the Backup operation for more info: STSADM's Backup Operation - TechNet I would recommend the Backup operation ...


5

The two main options I would consider are: Create a template with content from the Blog site. This will give you a .stp file that can be added to the site template gallery of any new site. This can be done completely through the UI. Run the stsadm export command to do a backup of the sub-site.


5

As you need to move your SQL servers, this can and will be treated as a simple SQL server move, which requires a farm migration. This is because the domain name of the SQL server changes. For farm migration, you can find instructions at http://technet2.microsoft.com/Office/en-us/library/42511e01-ecdd-4dc5-b06f-35aaada8a5d81033.mspx?mfr=true. Make sure you ...


5

I recently ran into the exact same issue in SP 2013 where my Dev machine had the RTM install and the target server the June CU. We ended up copying the Content Database from SQL directly, reattaching and associating it to a Web Application and it worked flawlessly. It seems the Restore command is no longer backwards compatible and can't be relied to restore ...


5

There are a couple of things you can try... such as 1. Get-SPDeletedSite & Remove-SPDeletedSite You may already have restored this site before. In that process you also deleted the site first (automatically), which you can find running the command... >Get-SPDeletedSite You'll see the site (or sites) listed, like this: WebApplicationId : ...


4

The most robust, free, plug-n-play solution I've found was this vbscript: Option Explicit ' Email source address Const strFrom = "email@example.com" 'Email destination address Const strTo = "email@example.com" ' Mail server address Const strMailserver = "smtp.host.com" 'Mail Server Schema Const strSchema = ...


4

The regular SharePoint backups will grab content, and configuration (when doing the farm backup). This does not backup any changes made to the SharePoint files on the server(s) such as images, templates, etc. Any customizations or third party tools that were deployed; note all should be deployed via a WSP. Some manual web.config changes may not be saved ...


4

Doing the SQL Server backup of the content databases is almost identical to what you are doing with the PowerShell script: protecting your content. This is of course the most important thing that you will want to protect. The advantage that doing these backups through a maintenance plan on SQL gives you is that you can perform both full and differential ...


3

This has long been an issue as the workflow data is actually kept separately from the actual form itself. However, the best way to manage this to be able to restore is to have the data contained within the form. Let the workflow run, but the actual statuses should be based on fields in the workflow, then your status will always be restored when you restore ...


3

In the past, what I've done is restore the backup to a spearate site collection via stsadm. Then from that backup, I export the subsite. I then import that into the original site collection. Check out the STSADM commands, ther are a lot of switches for export. Some 3rd party tools make recovery a lot easier like things from Docave, Quest and the like, ...


3

As you stated - "create a sheduled task that runs either power-shell or stsadm command". No other options for now and it would be nice to have option of built-in automatic backup in future version of sharepoint And here is a good post how to do it - Backup site collection.


3

In your example you are backing up the root site collection of machine1 and restoring it under a managed path on machine2. You may want to make those consistent. Emad is correct about step #2, as long as the application is setup on the server you will not need to create a content db. One last tip, make sure that you have any customizations or solutions ...


3

The actual time of a backup will depend on a few things Size of the database Hard drives being backed up from, are they fragmented, older, slower, etc. Existing activity on the server during the backup Backup destination, library vs network share vs SAN, etc. The first one is easy to find out, and is really the biggest factor. There will be a difference ...


3

The way I would do this is to move the site collection into its own content database. Then copy that database and attach it to the new farm. In Central Admin add a new content database to the web application Use the Move-SPSite CMDLET in PowerShell to move the site collection to the new content database Make a SQL backup of the content database Restore ...


3

Backup-SPSite will move all your data and rights and create corresponding records in the content DB. Import-Export is not so good way for you, you can use it only for web, not for site collection, but it also will move all your data and security, if you will set corresponding flags, it has a lot of options. Previous approach is also possible, you can attach ...


3

Here is the quick summary of upgrade: Verify the hardware requirements first. Try to back up the database from SharePoint 2007 using the SQL Server Management studio. Move the backup file to SharePoint 2010 environment and restore the backup file in SQL Server in a New Database (say DB1_2010) Before you attach the DB to web app, run the following ...


3

Have you also restored the Metadata Service database to the Production System? I am pretty sure that the metadata fields store GUID of terms as values and even if the NAMES of terms are same both in Model and Prod if they were created by hand their GUIDs will be different and this way in you Prod the system encounters unknown GUIDs and alerts to you with ...


3

Personally, If you are not strapped for space, I would both back up content and configuration as well as using your regular backups. Technically, you do not need to back up the content as well as have a backup of the sql instance, however they are really two different types of backups. One allows you to restore the site as a whole with everything on it to ...


3

Using the SharePoint PowerShell console Backup-SPFarm -Directory <BackupFolder> -BackupMethod {Full | Differential} -Item <WebApplicationName> [-Verbose] See this MSDN article: Use Windows PowerShell to back up a Web application in SharePoint Server. Use this command to restore a content DB: Restore-SPFarm -Directory <Backup folder ...


3

Here is what you should do: Run the task under designated service account e.g. CONTOSO\sp_powershell The account needs to have proper privilages, it needs SharePoint Shell Access (check Add-SPShellAdmin for more details)


3

No! you can't do that without SharePoint Installation, or with a client that could be connected to SharePoint Server In order to run Windows PowerShell remote you have to enable Windows Remote Management on the Server running SharePoint 2010 and the client that you want to run the commands from. On SharePoint Server Enable-PSRemoting Once remoting is ...


3

You can also do Implicit Remoting, which allows you to import all of the SP10 Powershell commands into a local session. The method described above works as well, but you are essentially running the commands from the server, so if you are on a server with different modules (such as Exchange 2010) you will have a difficuly time running those on the SharePoint ...



Only top voted, non community-wiki answers of a minimum length are eligible