Interestingly enough, given my experiences from last week, I am working
on a short disaster recovery how-to for SharePoint using BackupExec.

If you use a third-party solution, it MUST be SharePoint-aware;
otherwise you will destroy your portal.

I use MSDMBack.vbs which is included with SPS. A schedule task starts a
script. I create a backup  using msdmback and save to a backup location.
These script keeps 2 nights worth of backup at this location. Any
backups > then 2 days are removed. The network backup picks the sps
backup files and places them on tape drive.

Something to be aware of... Will you need version history contained in the
documents when you restore them? As well as the auxiliary information about
the document? Try a restore of a single doc that a coordinator deleted. Try
copying over one document from a portal that was restored to another
computer. If that extra information that goes with the document is important
to you...

What should we be aware of? That MSDMBack does not do this or BackupExec
does not do this? I am not sure about BackupExec, but I know MSDMBack
does not advertise it will do a single file restore.

Neither msdmback nor BackupExec does this. The version history is the real
issue.

Here is what I sent the PSS guy at Microsoft -- Additionally, you can
only recover the whole workspace, which includes revisions -- treat
SharePoint in this respect as being very similar to Exchange: i.e. what
you have in backup  for SharePoint is identical to a "non-brick-level"
backup in Exchange.

Now without further ado (I will clean this up some for Martin to post
somewhere):

Pre-Requisites for this procedure:
1) BackupExec 8.6 for Win 2k, Build 3878, fully patched for SharePoint
2) Backup Job must include O/S drive, SharePoint backup, and System
State.

Procedure:
1) Uninstall SharePoint completely per KBA Q295704
2) Reboot server
3) Install SPS from original media
4) Install SPS SP1
5) Reboot server
6) From the BackupExec Media server, run  a full restore of the O/S
drive, SharePoint backup, and System State
7) Using the SHUTDOWN tool from the Resource Kit, remotely reboot the
SharePoint server
8) Verify access to the workspaces
9) Run a backup from the BackupExec Media server of the O/S drive,
SharePoint data, and the System State.

Caveats:
1) If the SharePoint data  is on the same drive as the O/S, make sure to
exclude that directory during the normal file backup of that drive.
2) SharePoint must be fully running with no errors before attempting
this procedure -- otherwise you will end up with -1018 errors and lead
you down a false path of long repair.
3) SharePoint must be backed up with the agent from BackupExec -- if
not, then the MSDM script is your only choice -- anything else will kill
SharePoint.
4) When uninstalling SharePoint, make note of what level you have
installed -- and only install up to that level.

Notes about the server I am using:
1) Win2K Server SP3
2) IE 6 SP1
3) All of the Critical Updates
4) Solely dedicated to SharePoint
5) Runs the workspaces  via SSL.

" Additionally, you can
only recover the whole workspace, which includes revisions" That's what I
mean about the version history. Most documents stored  in sharepoint  store
some history and metadata. The metadata and the documents themselves are
stored in different places. If you want to restore the whole workspace
you're in good shape. If you want to restore anything at the "brick level"
then you need to restore to a different server. Then pull out your
documents. This will cause you to lose your history and metadata. This is
NOT to be confused with the ability to be able to restore any version of the
document from a backup  of a certain date. CommVault does this as do I
suspect some other products. But you will NOT get routing and approval info.
You will not get last changed info. Everything will show up as version 1.

I took this a couple steps further... 3 in fact. I keep five (5) backups
online using the following script:

---
C:\Program Files\SharePoint Portal Server\Bin>type nightly.bat
@echo off
move f:\sps-back\backup.4 f:\sps-back\backup.5
move f:\sps-back\backup.3 f:\sps-back\backup.4
move f:\sps-back\backup.2 f:\sps-back\backup.3
move f:\sps-back\backup.1 f:\sps-back\backup.2
move f:\sps-back\backup.bak f:\sps-back\backup.1
c:\winnt\system32\cscript "c:\program files\sharepoint portal
server\bin\msdmbac
k.vbs" /b f:\sps-back\backup.bak"
---

I went to five (5) because of how unstable sharepoint  has been for me. The
backup process sometimes just hangs, even though WEBDAV and notifications
are working and then I get a 0 sized backup  file. I might miss this for a
couple of days.

Creating the above files helps because then my tape backup software  kicks in
and grabs them. I have the backup software (Legato in my case) skip all the
sharepoint and exchange files.

Of course, at this point, my backup file is only 4 or 5GB, so I can easily
get away with this kind of number of backups. My filesystem is a 300GB RAID
system, so when it gets bigger, I'll have to re-script it so that it stores
it on a remote filesystem or use scp/ssh to put them somewhere else.

This nightly.bat is a scheduled task in win2k.