Wednesday, 22 April 2009

SBS 2008 Backup and Volume Shadow Copy Scheduling

When setting up a new SBS 2008, it is important to keep in mind that the schedule for the built-in SBS 2008 backup and the Volume Shadow Copy snapshots should not overlap.

When we schedule the SBS backup, we set the following times:

  • 1200hrs (12PM)
  • 1700hrs (5PM)
  • 2300hrs (11PM)

For the Volume Shadow Copies we set a schedule that is based on the volume of data changes that happen at the client site. For sites that have a high volume of data changing on any given day during their peak season we will reduce the number of VSC snapshots.

A rule of thumb for scheduling the snapshots:

  • 0817hrs (8:17AM)
  • 1017hrs (10:17AM – Coffee/Tea break)
  • 1217hrs (12:17PM – Lunch break)
  • 1517hrs (3:17PM – Coffee/Tea break)
  • 1817hrs (6:17PM – End of day)

We put the 17 minutes adjustment in as a just in case to avoid the snapshots running at the same time as any hourly scheduled tasks.

Note that, to date the built-in SBS 2008 backup is absolutely phenomenal for recovery purposes.

Philip Elder
MPECS Inc.
Microsoft Small Business Specialists
Co-Author: SBS 2008 Blueprint Book

*All Mac on SBS posts will not be written on a Mac until we replace our now missing iMac! (previous blog post)

Windows Live Writer

4 comments:

stryqx said...

A great technique for SBS 2008 Premium users is the following:

Create the same shared folder on both servers. This then houses all the shared files for the network.
Use DFS to set up a DFS namespace and adding the shared folders as a DFS link.
Use DFS-R to set up a replication group to replicate the shared folders.
Set up shadow copies on the Win2008 box to occur regularly (hourly for example).
Set up WSB on the SBS box to whatever you need.

If you need to retreive files, set your DFS referral to the Win2008 box and view the previous versions.

Also, since your shared folders are in DFS, you no longer need to worry about server name changes on hardware migration.

Even more brilliant is that DFS helps get files to/from branch office servers without needing to push out backup devices or agents to the branch offices.

Philip Elder Cluster MVP said...

Chris,

Excellent! Thank you very much for the great information.

We will look at deploying DFS in a lab setup to get a feel for how things work in Win2K8.

We had looked at it previously, but at the time the "R2" in the SBS 2003 product was not the same as the Win2K3 R2 product.

Philip

stryqx said...

Please note that intrasite DFS referral is random, so this scenario isn't great where concurrency to files is controlled with file locks.

A workaround is to set really long referral timeouts and manually set the active DFS referral.

Otherwise you need to use something like PeerLock (http://www.dfsfilelocking.com).

Hopefully Windows Server 2010 will add distributed file locking to DFS, making this unnecessary (wishful thinking based on the last paragraph at http://blogs.technet.com/askds/archive/2009/02/20/understanding-the-lack-of-distributed-file-locking-in-dfsr.aspx).

stryqx said...

You could still do it with SBS 2003 R2, but you were limited to File Replication Service (NtFrs) instead of DFS Replication (DFS-R).