Thanks Matthew, that's the exact document I've been wading through and trying to impress upon the reluctant peers responsible for DR and backups.
As for the Web Part Page mystery, I've not run into it myself and just wanted to ensure I never had to. :) Backing up the Office binaries was a good tip. Something which I've now added to our current plan. Are you doing full or incremental farm backups via stsadm? Or are you backing up each at an application or sitecollection level? From: [email protected] [mailto:[email protected]] On Behalf Of Matthew Cosier Sent: Thursday, 29 January 2009 1:02 PM To: [email protected] Subject: Re: Farm Backups [SEC=UNCLASSIFIED] I really don't see how that would be even possible? Perhaps when you did the restore, an update had been applied inbetween the time you took the backup, causing there to be some sync issues? I've actually just got finished writing end-to-end DR strategy documentation. The best reference that I could find on this, is located here: http://go.microsoft.com/fwlink/?LinkId=102839&clcid=0x409 I *highly recommend* taking a read through that whitepaper. Essentially, I plan on executing stsadm backups as well as the standard SQL Server database backups. During restore time I have suggested different paths for the different DR scenarios - for instance, recovering one site, recovering the entire farm, recovering after failed patch/service pack update/etc. Note that you should be taking file system backups of the 12 hive, as well as the office 12 binaries, and keep both that and the DB backups in order. Also, make sure that you are executing your DB backups BEFORE you execute your stsadm backups, because the stsadm backup actually truncates the log file, which you don't want before a DB backup. Also, if you just so happened to restore the SP central administration database and configuration databases via SQL backup, expect "Random errors to occur" - these random errors that Microsoft talk about, might be your missing views/web part settings? no idea. However, this is an unsupported path by Microsoft - you should be noting down all of your settings (service settings/web apps/export AAM settings via stsadm, etc) in order to recreate the configuration on a recovery. Let me know if you need any other information about this, I've been dabbling here for a few days. M On Thu, Jan 29, 2009 at 12:46 PM, Paul Noone <[email protected]<mailto:[email protected]>> wrote: Hi Uzma, Just following up in the event you have found a solution to this. I haven't tried doing a full restore yet but don't want to risk all my web part pages reverting. Is this a known bug, or is there another way to prevent this? Regards, Paul From: [email protected]<mailto:[email protected]> [mailto:[email protected]<mailto:[email protected]>] On Behalf Of Uzma Naz Sent: Wednesday, 21 January 2009 7:54 PM To: [email protected]<mailto:[email protected]> Subject: RE: Farm Backups I've learned that the STSADM has been quite unreliable when backing up an entire farm. I've used SQL back ups and the only hiccups I have found is that customised web part views switch back to default, anything that you might have changed will be reverted back. Not ideal if you're working for a client that will have 50 to 250 sites, imagine manually changing all views like that! Like Paul, I'm waiting on a good solution from Microsoft without the extra costing to run a backup - What I've done is held a list of what WSPs and site templates I have used, updating it as I go along with my development, performing weekly backups and differentials too. If anything goes haywire, I'll be able to restore with minimal disruption. In an ideal world, a bigger corporation needs to have a backup server so if a server goes down, the other one kicks in and allows the administrator to do it's business. Big Sighs with MOSS! Uzma ________________________________ Date: Wed, 21 Jan 2009 18:24:36 +1030 From: [email protected]<mailto:[email protected]> Subject: RE: Farm Backups To: [email protected]<mailto:[email protected]> I have always said... farm backup = SQL Backup. Everything else should be documented and can be recreated. You should never be modifying any files directly on the file system but only deploying custom stuff via WSP files. Cheers Paul Turner. From: [email protected]<mailto:[email protected]> [mailto:[email protected]<mailto:[email protected]>] On Behalf Of Paul Noone Sent: Wednesday, 21 January 2009 12:13 PM To: [email protected]<mailto:[email protected]> Subject: Farm Backups I've now been right through every TechNet article on this topic and I am still the none the wiser as to how to perform a "complete" farm backup and in-place restore using built-in tools (read STSADM and MSSQL and, in our case, VM images). I'm trying to develop straight-forward robust solutions for both DR and more general backup/restore requirements. There are two things which I would still dearly love clarified: * Deleting existing site collections before restoring in-place o This takes one helluva leap of faith. o Is this absolutely required and why? o Is there an alternative solution? * Custom solutions o Does any sort of farm-level backup include the solution store? o If so, is it recommended to include this? o The only other option of redeploying every solution again seems a bit painful. Still looking for a definitive, step-by-step guide to performing these tasks. I appreciate that there is probably no one-click solution available. If there is, we certainly can't afford it (R1, AvePoint?). But if anyone has developed/found one and is willign to share, please let me know! Kind regards, Paul ________________________________ Support procedure: https://www.codify.com/lists/support List address: [email protected]<mailto:[email protected]> Subscribe: [email protected]<mailto:[email protected]> Unsubscribe: [email protected]<mailto:[email protected]> List FAQ: http://www.codify.com/lists/ozmoss Other lists you might want to join: http://www.codify.com/lists ________________________________ Support procedure: https://www.codify.com/lists/support List address: [email protected]<mailto:[email protected]> Subscribe: [email protected]<mailto:[email protected]> Unsubscribe: [email protected]<mailto:[email protected]> List FAQ: http://www.codify.com/lists/ozmoss Other lists you might want to join: http://www.codify.com/lists ________________________________ Are you a PC? Upload your PC story and show the world<http://clk.atdmt.com/UKM/go/122465942/direct/01/> ________________________________ Support procedure: https://www.codify.com/lists/support List address: [email protected]<mailto:[email protected]> Subscribe: [email protected]<mailto:[email protected]> Unsubscribe: [email protected]<mailto:[email protected]> List FAQ: http://www.codify.com/lists/ozmoss Other lists you might want to join: http://www.codify.com/lists ________________________________ Support procedure: https://www.codify.com/lists/support List address: [email protected]<mailto:[email protected]> Subscribe: [email protected]<mailto:[email protected]> Unsubscribe: [email protected]<mailto:[email protected]> List FAQ: http://www.codify.com/lists/ozmoss Other lists you might want to join: http://www.codify.com/lists ________________________________ Support procedure: https://www.codify.com/lists/support List address: [email protected]<mailto:[email protected]> Subscribe: [email protected]<mailto:[email protected]> Unsubscribe: [email protected]<mailto:[email protected]> List FAQ: http://www.codify.com/lists/ozmoss Other lists you might want to join: http://www.codify.com/lists ________________________________ Support procedure: https://www.codify.com/lists/support List address: [email protected]<mailto:[email protected]> Subscribe: [email protected]<mailto:[email protected]> Unsubscribe: [email protected]<mailto:[email protected]> List FAQ: http://www.codify.com/lists/ozmoss Other lists you might want to join: http://www.codify.com/lists ________________________________ Support procedure: https://www.codify.com/lists/support List address: [email protected] Subscribe: [email protected] Unsubscribe: [email protected] List FAQ: http://www.codify.com/lists/ozmoss Other lists you might want to join: http://www.codify.com/lists -------------------------------------------------------------------------------- Support procedure: http://www.codify.com/lists/support List address: [email protected] Subscribe: [email protected] Unsubscribe: [email protected] List FAQ: http://www.codify.com/lists/ozmoss Other lists you might want to join: http://www.codify.com/lists
