Another thing I've seen become a problem is the diminishing disk space on the 
farm VMs due to logs and other things. One mistake we may have made was to 
install MOSS on C rather than a separate partition that could have been more 
easily resized.

With regards to logs, has anyone uncovered a canny way of moving them all (IIS, 
diagnostic and usage) to another location which can be accessed by all servers 
in the farm? Is this even possible?

From: [email protected] [mailto:[email protected]] On Behalf Of Matthew Cosier
Sent: Thursday, 29 January 2009 2:44 PM
To: [email protected]
Subject: Re: Farm Backups [SEC=UNCLASSIFIED]

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]<mailto:[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. :)



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]> 
[mailto:[email protected]<mailto:[email protected]>] On Behalf Of Matthew Cosier
Sent: Thursday, 29 January 2009 1:02 PM
To: [email protected]<mailto:[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]<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

Reply via email to