Awesome :) Yeah I hope we don't run into that one - that's why, once you've put together a DR plan + scenarios, testing it is paramount. Execute the full backup strategy, then execute the recovery in a virtual machine (at least).
I've suggested a scheduled full weekly backup, then nightly differential. I'm not too sure how that's going to play out yet, it might turn out to be bi-weekly full, with 3daily differential. M On Thu, Jan 29, 2009 at 1:14 PM, Paul Noone < [email protected]> wrote: > 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. J > > > > 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]> 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]] *On Behalf Of *Uzma > Naz > *Sent:* Wednesday, 21 January 2009 7:54 PM > *To:* [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] > Subject: RE: Farm Backups > To: [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]] *On Behalf Of *Paul > Noone > *Sent:* Wednesday, 21 January 2009 12:13 PM > *To:* [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] > > 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: 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 > > > ------------------------------ > > 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] > > 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: 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: 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: 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: 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: 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
