New Backup Solution

I'm going to be replacing my 72GB (3x36GB) RAID 5 with a 292GB (3x146GB)
RIAD 5 and will also need to change my backup strategy. I'm currently using
a DAT72 tape drive with SBS2003 and I'm slowing excluding more and more from
the backup so it will fit on the tapes (don't worry... using an external USB
w/ Robocopy for the rest).

Keeping SBS2008 in mind, I'm contemplating just using external USB drives
but I've been given a competitive quote on Backup Exec (for SBS) with a DLT
160/320 tape solution and I'm told that this is far superior to the native
SBS backup. Price wise, I could buy a lot of portable external USB drives
and use the free NT Backup for the price of the Backup Exec/Tape solution.

I know Backup Exec includes an Exchange Agent and an add-on SQL Agent but
what if I were to setup my future SBS2008 in a Hyper-V 1+1 scenario? Does
Backup Exec cover this as well? What about NT Backup?

My gut is telling me to just go with USB drives as it seems the most popular
option in the newsgroups...

SBS2003 Standard with SQL 2005 Standard on another Win2k3 server.

Allan... thanks so much. I'm very interested after reading a little on
their website and seeing that this is a very affordable solution.
Yes, our hardware is getting older as well and I'm starting to feel insecure
about it but don't really want to replace it since it's been rock solid
since day one.

So if I'm reading correctly, with SP, if our SBS were to go down hard
(motherboard failure), I could restore the last SBS backup to a MS Virtual
Server running elsewhere and keep on chugging along while my "real" SBS is
repaired, and then restore the virtual SBS back onto the physical server?
Am I dreaming?

I like the idea of having the local IDE/SATA drive on the server and then
copying to removable storage for offsite. So do you still have a rotation
like tape or does the image based backup preclude needing this type of
strategy for USB?

Appreciate all your help!

-Scott

"Al Williams" <> wrote in message
news:...
> Sounds very similar to our old situation - using tape and having to do
> custom backups with NTBackup to make them fit, wondering if you missed
> anything, wondering if you could handle a full disaster recovery...
>
> We switched over to ShadowProtect SBS (SP) last year and haven't looked
> back. I am able to do backups every 2 hours during the day without issues
> (how often you can backup is based more on the size of your backup
> drives). It integrates fully into VSS so Exchange & SQL are fully backed
> up using MS-methods. Their hardware independent restore (HIR) really
> works and their backup system is much quicker and efficient than using
> NTBackup any day. It also works with SBS2008 (although 2008's native
> backup has gotten good reviews but I am unsure that it can handle HIR).
>
> http://www.storagecraft.com/shadow_protect_SBS.php
>
> Best part, it was easy to actually test and document a disaster recovery
> scenario -- I could restore my SBS server OS/exchange/SQL/ISA to
> completely different hardware in an hour (a little longer with all our
> data) plug in a domain laptop and go -- it worked flawlessly (once you
> update drivers, etc.) and has saved me some sleep as our server hardware
> is a little older than it should be ;-)
>
> Some notes on how I use SP:
>
> 1) Schedule a NTBackup system state backup once a week when SP is not
> running just in case you need it.
> 2) To allow exchange logfiles to be properly handled you need to turn on
> the exchange VSS writer. Note that doing this precludes using SBSBackup
> but it sounds like you weren't using it anyway (workaround:
> http://blog.sbs-rocks.com/2009/06/be...nd-sbs-backup/)
> 3) I find it best to throw in a large un-raided IDE/SATA drive in the
> server and backup to that. I then use robocopy scripts triggered to run
> after SP finishes to copy the backups to multiple locations (including our
> external USB drive). You can have SP backup to the external drive
> directly, I just like this better as the backup will still run if someone
> forgets the external drive.
>
> I don't work for them I just really like the program, it has saved my
> bacon a couple times already. If you email them you can download a fully
> functional trial version.
> --
> Allan Williams
>
>
>
>
> Scott Rymer wrote:
>> I'm going to be replacing my 72GB (3x36GB) RAID 5 with a 292GB
>> (3x146GB) RIAD 5 and will also need to change my backup strategy. I'm
>> currently using a DAT72 tape drive with SBS2003 and I'm slowing
>> excluding more and more from the backup so it will fit on the tapes
>> (don't worry... using an external USB w/ Robocopy for the rest).
>>
>> Keeping SBS2008 in mind, I'm contemplating just using external USB
>> drives but I've been given a competitive quote on Backup Exec (for
>> SBS) with a DLT 160/320 tape solution and I'm told that this is far
>> superior to the native SBS backup. Price wise, I could buy a lot of
>> portable external USB drives and use the free NT Backup for the price
>> of the Backup Exec/Tape solution.
>> I know Backup Exec includes an Exchange Agent and an add-on SQL Agent
>> but what if I were to setup my future SBS2008 in a Hyper-V 1+1
>> scenario? Does Backup Exec cover this as well? What about NT Backup?
>>
>> My gut is telling me to just go with USB drives as it seems the most
>> popular option in the newsgroups...
>>
>> SBS2003 Standard with SQL 2005 Standard on another Win2k3 server.
>
>

Cliff... thanks for the very thorough response. As I was reading your
reply, I realised that the DLT tape solution woudln't fit my needs even now
as I would likely be in the same position of running out of backup space as
our data grows. This server also has an 18GB RAID 1 OS drive that needs
backing up. Also, when I do migrate to SBS2008 and if I wanted to run the
premium SQL server in another Hyper-V child, I'd have an even harder time
backup that server up. So, since I'm buying all new anyway, tape certainly
doesn't suit my needs.

So I'm going to look into both ShadowProtect (thanks Allan) and the
integrated SBS backup. Right now, with my ageing server, the ShadowProtect
route certainly seems to fit the bill...

One more question does come to mind... if I were to backup via the host in a
Hyper-V scenario, I would assume this wouldn't be Exchange or SQL aware...
so how does one purge logs, etc. that would naturally occur in the
integrated SBS backup?

Gotta go and read now... thanks a ton!


"Cliff Galiher" <> wrote in message
news:...
> Replies inline:
>
> -Cliff
>
>
> "Scott Rymer" <tsrymer/at/hotmail/dot/com> wrote in message
> news:A13A34F9-293A-4D8C-B180-...
>> I'm going to be replacing my 72GB (3x36GB) RAID 5 with a 292GB (3x146GB)
>> RIAD 5 and will also need to change my backup strategy. I'm currently
>> using a DAT72 tape drive with SBS2003 and I'm slowing excluding more and
>> more from the backup so it will fit on the tapes (don't worry... using an
>> external USB w/ Robocopy for the rest).
>
> Ugh. I feel your pain. Time to step up to something more manageable for
> sure.
>
>>
>> Keeping SBS2008 in mind, I'm contemplating just using external USB drives
>> but I've been given a competitive quote on Backup Exec (for SBS) with a
>> DLT 160/320 tape solution and I'm told that this is far superior to the
>> native SBS backup. Price wise, I could buy a lot of portable external
>> USB drives and use the free NT Backup for the price of the Backup
>> Exec/Tape solution.
>
> Backup Exec is definitely a higher-end product. No argument. However
> "superior" is in the eye of the beholder. A tractor-trailer is a superior
> vehicle in almost all regards to a minivan. Both are designed to
> transport "stuff" (unlike a sports-car, for example) but obviously the big
> rig outclasses the mini-van. That doesn't mean that soccer-moms should
> start driving big rigs everywhere.
>
> So, in my opinion, Backup Exec has a place, but for most SBS deployments,
> the SBS backup is actually the better solution. It is easier to set up,
> better integrated, and has all of the major features most people need.
>
> Ultimately, however, the only real way to make the decision between the
> two is to ask "what does Backup Exec do FOR ME that SBS backup doesn't."
> Backup to tape? Sure. But if you are buying new across the board, as it
> sounds like you are, is that a feature you NEED. Probably not, since you
> can buy external drives. Don't let a salesperson talk you into a solution
> just because it is "superior." Ask them WHY and decide if the features
> fit your needs and if the cost is worth it.
>
>> I know Backup Exec includes an Exchange Agent and an add-on SQL Agent but
>> what if I were to setup my future SBS2008 in a Hyper-V 1+1 scenario?
>> Does Backup Exec cover this as well? What about NT Backup?
>
> NTBackup is officially gone in '08. "Windows backup" is not even related,
> code-wise. Just an FYI. If someone were skimming, they could give you
> incorrect information since NTBackup is, feature-wise, different than the
> built-in backup on SBS.
>
> But address your question specifically, both products can handle Hyper-V.
> But *how* they handle hyper-v (or even if then need to) depends entirely
> on your backup strategy. There is a difference between running the backup
> within the guest OS where it behaves (and will restore) just like a
> traditional backup, and running the backup from the host, where a snapshot
> of the entire running OS occurs.
>
> Backup Exec can backup a guest OS from the host but it requires the
> purchase of another agent. Specifically you'll need a MS Virtual Server
> agent for Backup Exec. Windows Backup can also backup virtual machines
> from the parent partition as long as you register the Hyper-V VSS Writer.
> There is a technet article on how to do this and the process is simple,
> but I won't bother posting more about this yet since it really isn't
> relevant to the conversation. All that is important is that it *can* be
> done.
>
> One important thing to consider here is that in a 1+1 setup, your SBS
> server is going to be a child OS, so the "Windows Backup" path for backing
> up the hyper-V OS will *not* be set up in SBS. For the backup to run via
> hyper-v, you need to do so in the parent OS, so you'd use the standalone
> Windows Backup program on the parent OS, which is not SBS integrated. But
> neither is Backup Exec, so ultimately it is a wash.
>
> Ultimately you have to decide why you'd want to back up a guest OS from
> the host. I don't want to imply that you can't or shouldn't do this; there
> are benefits to backing up guest OS's from the host. But neither do I
> want to imply that it is necessary. Backups can certainly still be run in
> the guest OS without ever being aware that they are running in a hyper-v
> server since hyper-v drivers appear real to the guest OS. Backup products
> can be blissfully unaware.
>
> There are trade-offs with each approach, and you could, of course, do
> guest AND host backups to get the best of both worlds. There is still a
> cost though. this time in storage space. A *lot* of space. You are
> essentially getting two backups of every server every time. So there is a
> lot of thought that must go into a DR plan, regardless of product, when
> you add hyper-v. Most of those decisions need to be driven by a needs
> assessment. There is no shortcut.
>
> ...which brings us full circle. Yes, you *can* backup hyper-v guests with
> either product, but *how* you back them up is the question.
>
>> My gut is telling me to just go with USB drives as it seems the most
>> popular option in the newsgroups...
>
> Don't go with your gut any more than you should go with a salesman's
> recommendation blindly. The only way to make this decision is to sit
> down, make a list of what you need, and then choose the product that fits
> those needs. It takes time. It takes planning. Google disaster recovery
> whitepapers. Read. Set up a test machine to use the products you are
> considering. Get a feel for their UIs, then decide which product has the
> best cost/benefit ratio for your needs.

To answer your final question, I can only answer it for the Windows Backup.
I have not looked into the details of how the MS Virtual Server agent for
Backup Exec works, so there may be differences.

The short answer is that the host OS for a Windows Backup does not need to
specifically be Exchange or SQL aware since that isn't how host OS backups
work or how hey are intended to be restored. One of the things the host OS
does during the backup, however, is calls the various VSS writers that are
registered. To backup up VMs, the hyper-v VSS writer must be registered as
I previously mentioned.

The Hyper-V VSS writer exists because of the "special" things it does above
and beyond the file-level snapshots that the standard VSS writer does. One
of those special things is that, as long as the integration components are
installed on the guest OS, is that it passes on the VSS snapshot requests to
any registered VSS writers in the guest OS. This includes any SQL and
Exchange VSS writers that are present, as well as any other custom
application VSS writers that may be installed.

Essentially, although the host OS is not "explicitly" aware of Exchange or
SQL, as long as the guest OS is app aware and properly configured to talk to
the host, the end result is the same. It is a cooperative effort between
the hyper-V VSS writer and the guest OS VSS writers where the host OS will
trust the guest OS to do what needs to be done. In turn, the guest OS will
ensure that its applications are in a consistent state, so Exchange and SQL
are ready to roll if the guest OS is restored. No hanging transactions or
logs.

This also should answer your question about log pruning. This isn't a result
of the SBS backup specifically, but is done because the application is aware
if it has been backed up. And the application is made aware of its state of
backup because of its VSS writer. The architecture I outlined above shows
that the guest OS VSS writers are called so the apps are aware they've been
backed up and, in turn, the logs will be handled in the same way they'd be
handled if the backup was run natively in the guest OS; however you've
configured that to be.

Hope that helps,

-Cliff


"Scott Rymer" <tsrymer/at/hotmail/dot/com> wrote in message
news:...
> Cliff... thanks for the very thorough response. As I was reading your
> reply, I realised that the DLT tape solution woudln't fit my needs even
> now as I would likely be in the same position of running out of backup
> space as our data grows. This server also has an 18GB RAID 1 OS drive
> that needs backing up. Also, when I do migrate to SBS2008 and if I wanted
> to run the premium SQL server in another Hyper-V child, I'd have an even
> harder time backup that server up. So, since I'm buying all new anyway,
> tape certainly doesn't suit my needs.
>
> So I'm going to look into both ShadowProtect (thanks Allan) and the
> integrated SBS backup. Right now, with my ageing server, the
> ShadowProtect route certainly seems to fit the bill...
>
> One more question does come to mind... if I were to backup via the host in
> a Hyper-V scenario, I would assume this wouldn't be Exchange or SQL
> aware... so how does one purge logs, etc. that would naturally occur in
> the integrated SBS backup?
>
> Gotta go and read now... thanks a ton!
>
>
> "Cliff Galiher" <> wrote in message
> news:...
>> Replies inline:
>>
>> -Cliff
>>
>>
>> "Scott Rymer" <tsrymer/at/hotmail/dot/com> wrote in message
>> news:A13A34F9-293A-4D8C-B180-...
>>> I'm going to be replacing my 72GB (3x36GB) RAID 5 with a 292GB (3x146GB)
>>> RIAD 5 and will also need to change my backup strategy. I'm currently
>>> using a DAT72 tape drive with SBS2003 and I'm slowing excluding more and
>>> more from the backup so it will fit on the tapes (don't worry... using
>>> an external USB w/ Robocopy for the rest).
>>
>> Ugh. I feel your pain. Time to step up to something more manageable for
>> sure.
>>
>>>
>>> Keeping SBS2008 in mind, I'm contemplating just using external USB
>>> drives but I've been given a competitive quote on Backup Exec (for SBS)
>>> with a DLT 160/320 tape solution and I'm told that this is far superior
>>> to the native SBS backup. Price wise, I could buy a lot of portable
>>> external USB drives and use the free NT Backup for the price of the
>>> Backup Exec/Tape solution.
>>
>> Backup Exec is definitely a higher-end product. No argument. However
>> "superior" is in the eye of the beholder. A tractor-trailer is a
>> superior vehicle in almost all regards to a minivan. Both are designed
>> to transport "stuff" (unlike a sports-car, for example) but obviously the
>> big rig outclasses the mini-van. That doesn't mean that soccer-moms
>> should start driving big rigs everywhere.
>>
>> So, in my opinion, Backup Exec has a place, but for most SBS deployments,
>> the SBS backup is actually the better solution. It is easier to set up,
>> better integrated, and has all of the major features most people need.
>>
>> Ultimately, however, the only real way to make the decision between the
>> two is to ask "what does Backup Exec do FOR ME that SBS backup doesn't."
>> Backup to tape? Sure. But if you are buying new across the board, as it
>> sounds like you are, is that a feature you NEED. Probably not, since you
>> can buy external drives. Don't let a salesperson talk you into a
>> solution just because it is "superior." Ask them WHY and decide if the
>> features fit your needs and if the cost is worth it.
>>
>>> I know Backup Exec includes an Exchange Agent and an add-on SQL Agent
>>> but what if I were to setup my future SBS2008 in a Hyper-V 1+1 scenario?
>>> Does Backup Exec cover this as well? What about NT Backup?
>>
>> NTBackup is officially gone in '08. "Windows backup" is not even
>> related, code-wise. Just an FYI. If someone were skimming, they could
>> give you incorrect information since NTBackup is, feature-wise, different
>> than the built-in backup on SBS.
>>
>> But address your question specifically, both products can handle Hyper-V.
>> But *how* they handle hyper-v (or even if then need to) depends entirely
>> on your backup strategy. There is a difference between running the
>> backup within the guest OS where it behaves (and will restore) just like
>> a traditional backup, and running the backup from the host, where a
>> snapshot of the entire running OS occurs.
>>
>> Backup Exec can backup a guest OS from the host but it requires the
>> purchase of another agent. Specifically you'll need a MS Virtual Server
>> agent for Backup Exec. Windows Backup can also backup virtual machines
>> from the parent partition as long as you register the Hyper-V VSS Writer.
>> There is a technet article on how to do this and the process is simple,
>> but I won't bother posting more about this yet since it really isn't
>> relevant to the conversation. All that is important is that it *can* be
>> done.
>>
>> One important thing to consider here is that in a 1+1 setup, your SBS
>> server is going to be a child OS, so the "Windows Backup" path for
>> backing up the hyper-V OS will *not* be set up in SBS. For the backup to
>> run via hyper-v, you need to do so in the parent OS, so you'd use the
>> standalone Windows Backup program on the parent OS, which is not SBS
>> integrated. But neither is Backup Exec, so ultimately it is a wash.
>>
>> Ultimately you have to decide why you'd want to back up a guest OS from
>> the host. I don't want to imply that you can't or shouldn't do this;
>> there are benefits to backing up guest OS's from the host. But neither
>> do I want to imply that it is necessary. Backups can certainly still be
>> run in the guest OS without ever being aware that they are running in a
>> hyper-v server since hyper-v drivers appear real to the guest OS. Backup
>> products can be blissfully unaware.
>>
>> There are trade-offs with each approach, and you could, of course, do
>> guest AND host backups to get the best of both worlds. There is still a
>> cost though. this time in storage space. A *lot* of space. You are
>> essentially getting two backups of every server every time. So there is
>> a lot of thought that must go into a DR plan, regardless of product, when
>> you add hyper-v. Most of those decisions need to be driven by a needs
>> assessment. There is no shortcut.
>>
>> ...which brings us full circle. Yes, you *can* backup hyper-v guests
>> with either product, but *how* you back them up is the question.
>>
>>> My gut is telling me to just go with USB drives as it seems the most
>>> popular option in the newsgroups...
>>
>> Don't go with your gut any more than you should go with a salesman's
>> recommendation blindly. The only way to make this decision is to sit
>> down, make a list of what you need, and then choose the product that fits
>> those needs. It takes time. It takes planning. Google disaster
>> recovery whitepapers. Read. Set up a test machine to use the products
>> you are considering. Get a feel for their UIs, then decide which product
>> has the best cost/benefit ratio for your needs.
>

It certainly does help... Thanks again!

"Cliff Galiher" <> wrote in message
news:...
> To answer your final question, I can only answer it for the Windows
> Backup. I have not looked into the details of how the MS Virtual Server
> agent for Backup Exec works, so there may be differences.
>
> The short answer is that the host OS for a Windows Backup does not need to
> specifically be Exchange or SQL aware since that isn't how host OS backups
> work or how hey are intended to be restored. One of the things the host
> OS does during the backup, however, is calls the various VSS writers that
> are registered. To backup up VMs, the hyper-v VSS writer must be
> registered as I previously mentioned.
>
> The Hyper-V VSS writer exists because of the "special" things it does
> above and beyond the file-level snapshots that the standard VSS writer
> does. One of those special things is that, as long as the integration
> components are installed on the guest OS, is that it passes on the VSS
> snapshot requests to any registered VSS writers in the guest OS. This
> includes any SQL and Exchange VSS writers that are present, as well as any
> other custom application VSS writers that may be installed.
>
> Essentially, although the host OS is not "explicitly" aware of Exchange or
> SQL, as long as the guest OS is app aware and properly configured to talk
> to the host, the end result is the same. It is a cooperative effort
> between the hyper-V VSS writer and the guest OS VSS writers where the host
> OS will trust the guest OS to do what needs to be done. In turn, the
> guest OS will ensure that its applications are in a consistent state, so
> Exchange and SQL are ready to roll if the guest OS is restored. No
> hanging transactions or logs.
>
> This also should answer your question about log pruning. This isn't a
> result of the SBS backup specifically, but is done because the application
> is aware if it has been backed up. And the application is made aware of
> its state of backup because of its VSS writer. The architecture I
> outlined above shows that the guest OS VSS writers are called so the apps
> are aware they've been backed up and, in turn, the logs will be handled in
> the same way they'd be handled if the backup was run natively in the guest
> OS; however you've configured that to be.
>
> Hope that helps,
>
> -Cliff
>
>
> "Scott Rymer" <tsrymer/at/hotmail/dot/com> wrote in message
> news:...
>> Cliff... thanks for the very thorough response. As I was reading your
>> reply, I realised that the DLT tape solution woudln't fit my needs even
>> now as I would likely be in the same position of running out of backup
>> space as our data grows. This server also has an 18GB RAID 1 OS drive
>> that needs backing up. Also, when I do migrate to SBS2008 and if I
>> wanted to run the premium SQL server in another Hyper-V child, I'd have
>> an even harder time backup that server up. So, since I'm buying all new
>> anyway, tape certainly doesn't suit my needs.
>>
>> So I'm going to look into both ShadowProtect (thanks Allan) and the
>> integrated SBS backup. Right now, with my ageing server, the
>> ShadowProtect route certainly seems to fit the bill...
>>
>> One more question does come to mind... if I were to backup via the host
>> in a Hyper-V scenario, I would assume this wouldn't be Exchange or SQL
>> aware... so how does one purge logs, etc. that would naturally occur in
>> the integrated SBS backup?
>>
>> Gotta go and read now... thanks a ton!
>>
>>
>> "Cliff Galiher" <> wrote in message
>> news:...
>>> Replies inline:
>>>
>>> -Cliff
>>>
>>>
>>> "Scott Rymer" <tsrymer/at/hotmail/dot/com> wrote in message
>>> news:A13A34F9-293A-4D8C-B180-...
>>>> I'm going to be replacing my 72GB (3x36GB) RAID 5 with a 292GB
>>>> (3x146GB) RIAD 5 and will also need to change my backup strategy. I'm
>>>> currently using a DAT72 tape drive with SBS2003 and I'm slowing
>>>> excluding more and more from the backup so it will fit on the tapes
>>>> (don't worry... using an external USB w/ Robocopy for the rest).
>>>
>>> Ugh. I feel your pain. Time to step up to something more manageable
>>> for sure.
>>>
>>>>
>>>> Keeping SBS2008 in mind, I'm contemplating just using external USB
>>>> drives but I've been given a competitive quote on Backup Exec (for SBS)
>>>> with a DLT 160/320 tape solution and I'm told that this is far superior
>>>> to the native SBS backup. Price wise, I could buy a lot of portable
>>>> external USB drives and use the free NT Backup for the price of the
>>>> Backup Exec/Tape solution.
>>>
>>> Backup Exec is definitely a higher-end product. No argument. However
>>> "superior" is in the eye of the beholder. A tractor-trailer is a
>>> superior vehicle in almost all regards to a minivan. Both are designed
>>> to transport "stuff" (unlike a sports-car, for example) but obviously
>>> the big rig outclasses the mini-van. That doesn't mean that soccer-moms
>>> should start driving big rigs everywhere.
>>>
>>> So, in my opinion, Backup Exec has a place, but for most SBS
>>> deployments, the SBS backup is actually the better solution. It is
>>> easier to set up, better integrated, and has all of the major features
>>> most people need.
>>>
>>> Ultimately, however, the only real way to make the decision between the
>>> two is to ask "what does Backup Exec do FOR ME that SBS backup doesn't."
>>> Backup to tape? Sure. But if you are buying new across the board, as it
>>> sounds like you are, is that a feature you NEED. Probably not, since
>>> you can buy external drives. Don't let a salesperson talk you into a
>>> solution just because it is "superior." Ask them WHY and decide if the
>>> features fit your needs and if the cost is worth it.
>>>
>>>> I know Backup Exec includes an Exchange Agent and an add-on SQL Agent
>>>> but what if I were to setup my future SBS2008 in a Hyper-V 1+1
>>>> scenario? Does Backup Exec cover this as well? What about NT Backup?
>>>
>>> NTBackup is officially gone in '08. "Windows backup" is not even
>>> related, code-wise. Just an FYI. If someone were skimming, they could
>>> give you incorrect information since NTBackup is, feature-wise,
>>> different than the built-in backup on SBS.
>>>
>>> But address your question specifically, both products can handle
>>> Hyper-V. But *how* they handle hyper-v (or even if then need to) depends
>>> entirely on your backup strategy. There is a difference between running
>>> the backup within the guest OS where it behaves (and will restore) just
>>> like a traditional backup, and running the backup from the host, where a
>>> snapshot of the entire running OS occurs.
>>>
>>> Backup Exec can backup a guest OS from the host but it requires the
>>> purchase of another agent. Specifically you'll need a MS Virtual Server
>>> agent for Backup Exec. Windows Backup can also backup virtual machines
>>> from the parent partition as long as you register the Hyper-V VSS
>>> Writer. There is a technet article on how to do this and the process is
>>> simple, but I won't bother posting more about this yet since it really
>>> isn't relevant to the conversation. All that is important is that it
>>> *can* be done.
>>>
>>> One important thing to consider here is that in a 1+1 setup, your SBS
>>> server is going to be a child OS, so the "Windows Backup" path for
>>> backing up the hyper-V OS will *not* be set up in SBS. For the backup
>>> to run via hyper-v, you need to do so in the parent OS, so you'd use the
>>> standalone Windows Backup program on the parent OS, which is not SBS
>>> integrated. But neither is Backup Exec, so ultimately it is a wash.
>>>
>>> Ultimately you have to decide why you'd want to back up a guest OS from
>>> the host. I don't want to imply that you can't or shouldn't do this;
>>> there are benefits to backing up guest OS's from the host. But neither
>>> do I want to imply that it is necessary. Backups can certainly still be
>>> run in the guest OS without ever being aware that they are running in a
>>> hyper-v server since hyper-v drivers appear real to the guest OS.
>>> Backup products can be blissfully unaware.
>>>
>>> There are trade-offs with each approach, and you could, of course, do
>>> guest AND host backups to get the best of both worlds. There is still a
>>> cost though. this time in storage space. A *lot* of space. You are
>>> essentially getting two backups of every server every time. So there is
>>> a lot of thought that must go into a DR plan, regardless of product,
>>> when you add hyper-v. Most of those decisions need to be driven by a
>>> needs assessment. There is no shortcut.
>>>
>>> ...which brings us full circle. Yes, you *can* backup hyper-v guests
>>> with either product, but *how* you back them up is the question.
>>>
>>>> My gut is telling me to just go with USB drives as it seems the most
>>>> popular option in the newsgroups...
>>>
>>> Don't go with your gut any more than you should go with a salesman's
>>> recommendation blindly. The only way to make this decision is to sit
>>> down, make a list of what you need, and then choose the product that
>>> fits those needs. It takes time. It takes planning. Google disaster
>>> recovery whitepapers. Read. Set up a test machine to use the products
>>> you are considering. Get a feel for their UIs, then decide which
>>> product has the best cost/benefit ratio for your needs.
>>

In article <A13A34F9-293A-4D8C-B180->, "Scott
Rymer" says...
>
> I'm going to be replacing my 72GB (3x36GB) RAID 5 with a 292GB (3x146GB)
> RIAD 5 and will also need to change my backup strategy. I'm currently using
> a DAT72 tape drive with SBS2003 and I'm slowing excluding more and more from
> the backup so it will fit on the tapes (don't worry... using an external USB
> w/ Robocopy for the rest).
>
> Keeping SBS2008 in mind, I'm contemplating just using external USB drives
> but I've been given a competitive quote on Backup Exec (for SBS) with a DLT
> 160/320 tape solution and I'm told that this is far superior to the native
> SBS backup. Price wise, I could buy a lot of portable external USB drives
> and use the free NT Backup for the price of the Backup Exec/Tape solution.
>
> I know Backup Exec includes an Exchange Agent and an add-on SQL Agent but
> what if I were to setup my future SBS2008 in a Hyper-V 1+1 scenario? Does
> Backup Exec cover this as well? What about NT Backup?
>
> My gut is telling me to just go with USB drives as it seems the most popular
> option in the newsgroups...
>
> SBS2003 Standard with SQL 2005 Standard on another Win2k3 server.

With USB drives you have SBS backup built-in ability to recover the
server from scratch with just the Install DVD and your RAID controller
drivers in a thumb drive if needed - it's that simple. You can even
select a point in time to do the bare metal restore from - I would not
purchase a third party backup solution unless you really want to use
tape.

Now, my preference is TAPE - I have used it for decades and find it to
be very reliable, more reliable than USB drives, but, like all backup
solutions it does require monitoring (which most people fail to do).
Tapes don't last for an infinite number of writes, but, they are always
cheaper than quality USB drives, but significantly smaller.

In the case of SOX compliance, the cost of 46 USB drives exceeds the
cost of 46 Tapes and the Tape drive.

If you're able to use just a couple USB drives then USB would be the
cheaper way to go, but I strongly caution you to purchase quality USB
external drives - ones with more than 3 year warranty.

--
You can't trust your best friends, your five senses, only the little
voice inside you that most civilians don't even hear -- Listen to that.
Trust yourself.
(remove 999 for proper email address)

Thanks for those details--I've been interested in that question for some
time, and this is a very clear explanation.

"Cliff Galiher" <> wrote in message
news:...
> To answer your final question, I can only answer it for the Windows
> Backup. I have not looked into the details of how the MS Virtual Server
> agent for Backup Exec works, so there may be differences.
>
> The short answer is that the host OS for a Windows Backup does not need to
> specifically be Exchange or SQL aware since that isn't how host OS backups
> work or how hey are intended to be restored. One of the things the host
> OS does during the backup, however, is calls the various VSS writers that
> are registered. To backup up VMs, the hyper-v VSS writer must be
> registered as I previously mentioned.
>
> The Hyper-V VSS writer exists because of the "special" things it does
> above and beyond the file-level snapshots that the standard VSS writer
> does. One of those special things is that, as long as the integration
> components are installed on the guest OS, is that it passes on the VSS
> snapshot requests to any registered VSS writers in the guest OS. This
> includes any SQL and Exchange VSS writers that are present, as well as any
> other custom application VSS writers that may be installed.

"Cliff Galiher" <> wrote in message
news:...
> Replies inline:
>
> Ultimately you have to decide why you'd want to back up a guest OS from
> the host. I don't want to imply that you can't or shouldn't do this; there
> are benefits to backing up guest OS's from the host. But neither do I
> want to imply that it is necessary. Backups can certainly still be run in
> the guest OS without ever being aware that they are running in a hyper-v
> server since hyper-v drivers appear real to the guest OS. Backup products
> can be blissfully unaware.

If you back up from the host won't the guest think, after a restore and
restart, that it just had its plug pulled?


--

The VSS writer is able to account for this. It does so by forcing a flush
of data to disk so the server is in a consistent state upon restore and, as
such, when the server is started back up, it is aware of this fact (a
feature of VSS.)

If a comparison must be drawn to a machine in a "shut down" state, it'd be
like pressing (not holding) the power button on a machine. This forces an
immediate shutdown process, flushing all data to disk, but does not hard-cut
the power, nor is a reason for the shutdown given or requires as is the case
with a software initiated shutdown.

It certainly is a far cry from pulling the plug on a machine, which
invariably leaves some trace evidence that something went wrong, even if the
data is still consistent. Exchange, for example, notes when it closes or
flushes a log file, as does AD. So upon restart of a machine that was
improperly shut down, exchange would notice that the last log file was never
closed and will initiate some extended checks. Similarly, if the OS notices
problems, that's when you see "rebuilding indices" or even NTFS level
checks.

VSS, on the other hand, flushes the data to disk, marks various log files
and OS components as consistent, depending on the needs of that component
(Which is why different VSS writers are required for different
applications), and then lets the backup software work off of the
now-consistent snapshot while the OS/exchange/SQL moves along doing other
things. Upon restore and start-up, the NTFS check is valid because the data
was marked appropriately, exchange sees the marker that the log file was
closed for the snapshot, and SQL Server passes its various checksum
operations. Thus these apps proceed without the tedium of the extra
integrity checks that a hard shutdown would incur.

Hope that makes sense.

-Cliff


"Tom Del Rosso" <> wrote in message
news:uDg$...
> "Cliff Galiher" <> wrote in message
> news:...
>> Replies inline:
>>
>> Ultimately you have to decide why you'd want to back up a guest OS from
>> the host. I don't want to imply that you can't or shouldn't do this;
>> there are benefits to backing up guest OS's from the host. But neither
>> do I want to imply that it is necessary. Backups can certainly still be
>> run in the guest OS without ever being aware that they are running in a
>> hyper-v server since hyper-v drivers appear real to the guest OS. Backup
>> products can be blissfully unaware.
>
> If you back up from the host won't the guest think, after a restore and
> restart, that it just had its plug pulled?
>
>
> --
>

I've never restored a ShadowProtect backup to a virtual machine myself, but
I've seen it demonstrated - the speaker restored a backup of his SBS to a VM
on his laptop and booted it up to show how easily it worked. Works great,
and you can then back up the VM and restore it back to the SBS as you
describe. (Not to mention that I'm pretty sure you can boot an SP backup in
VMWare without restoring - check their site for that).

I saw the coolest thing for SP backups at SMB Nation - a 2-bay High Rely
where one drive automatically mirrors to the other. So you attach this to
your server with USB or eSATA, and it shows as a single drive. As you back
up to that drive, the device mirrors one drive to the other, which can be
rotated for offsite. This way, you're not removing or replacing the drive
your server sees, which avoids "safely remote" and other errors of that
kind. And, they have fans and temperature monitoring, so you're likely to
get better drive life and reliability - I've had a High Rely enclosure going
on two years, and while I've had one power supply fail (external) and lost
one to a power incident (my fault), the drives and enclosures have been
bulletproof. And their support is excellent.
http://high-rely.com/HR3/includes/Ta.../TandemDXR.php


"Scott Rymer" <tsrymer/at/hotmail/dot/com> wrote in message
news:...
> Allan... thanks so much. I'm very interested after reading a little on
> their website and seeing that this is a very affordable solution.
> Yes, our hardware is getting older as well and I'm starting to feel
> insecure about it but don't really want to replace it since it's been rock
> solid since day one.
>
> So if I'm reading correctly, with SP, if our SBS were to go down hard
> (motherboard failure), I could restore the last SBS backup to a MS Virtual
> Server running elsewhere and keep on chugging along while my "real" SBS is
> repaired, and then restore the virtual SBS back onto the physical server?
> Am I dreaming?
>
> I like the idea of having the local IDE/SATA drive on the server and then
> copying to removable storage for offsite. So do you still have a rotation
> like tape or does the image based backup preclude needing this type of
> strategy for USB?
>
> Appreciate all your help!
>
> -Scott
>
> "Al Williams" <> wrote in message
> news:...
>> Sounds very similar to our old situation - using tape and having to do
>> custom backups with NTBackup to make them fit, wondering if you missed
>> anything, wondering if you could handle a full disaster recovery...
>>
>> We switched over to ShadowProtect SBS (SP) last year and haven't looked
>> back. I am able to do backups every 2 hours during the day without
>> issues (how often you can backup is based more on the size of your backup
>> drives). It integrates fully into VSS so Exchange & SQL are fully backed
>> up using MS-methods. Their hardware independent restore (HIR) really
>> works and their backup system is much quicker and efficient than using
>> NTBackup any day. It also works with SBS2008 (although 2008's native
>> backup has gotten good reviews but I am unsure that it can handle HIR).
>>
>> http://www.storagecraft.com/shadow_protect_SBS.php
>>
>> Best part, it was easy to actually test and document a disaster recovery
>> scenario -- I could restore my SBS server OS/exchange/SQL/ISA to
>> completely different hardware in an hour (a little longer with all our
>> data) plug in a domain laptop and go -- it worked flawlessly (once you
>> update drivers, etc.) and has saved me some sleep as our server hardware
>> is a little older than it should be ;-)
>>
>> Some notes on how I use SP:
>>
>> 1) Schedule a NTBackup system state backup once a week when SP is not
>> running just in case you need it.
>> 2) To allow exchange logfiles to be properly handled you need to turn on
>> the exchange VSS writer. Note that doing this precludes using SBSBackup
>> but it sounds like you weren't using it anyway (workaround:
>> http://blog.sbs-rocks.com/2009/06/be...nd-sbs-backup/)
>> 3) I find it best to throw in a large un-raided IDE/SATA drive in the
>> server and backup to that. I then use robocopy scripts triggered to run
>> after SP finishes to copy the backups to multiple locations (including
>> our external USB drive). You can have SP backup to the external drive
>> directly, I just like this better as the backup will still run if someone
>> forgets the external drive.
>>
>> I don't work for them I just really like the program, it has saved my
>> bacon a couple times already. If you email them you can download a fully
>> functional trial version.
>> --
>> Allan Williams
>>
>>
>>
>>
>> Scott Rymer wrote:
>>> I'm going to be replacing my 72GB (3x36GB) RAID 5 with a 292GB
>>> (3x146GB) RIAD 5 and will also need to change my backup strategy. I'm
>>> currently using a DAT72 tape drive with SBS2003 and I'm slowing
>>> excluding more and more from the backup so it will fit on the tapes
>>> (don't worry... using an external USB w/ Robocopy for the rest).
>>>
>>> Keeping SBS2008 in mind, I'm contemplating just using external USB
>>> drives but I've been given a competitive quote on Backup Exec (for
>>> SBS) with a DLT 160/320 tape solution and I'm told that this is far
>>> superior to the native SBS backup. Price wise, I could buy a lot of
>>> portable external USB drives and use the free NT Backup for the price
>>> of the Backup Exec/Tape solution.
>>> I know Backup Exec includes an Exchange Agent and an add-on SQL Agent
>>> but what if I were to setup my future SBS2008 in a Hyper-V 1+1
>>> scenario? Does Backup Exec cover this as well? What about NT Backup?
>>>
>>> My gut is telling me to just go with USB drives as it seems the most
>>> popular option in the newsgroups...
>>>
>>> SBS2003 Standard with SQL 2005 Standard on another Win2k3 server.
>>
>>
>