Backup method prior to patching

Dear All,

reading varying feedbacks about the success of patching and following
problems with SBS2000, I was wondering how to implement sort of a
rollback capability before patching the system (or even installing
critical software).

I am less concerned about losing data (as backups are frequently done)
but more about the system aspects.

I see several possibilities to 'rollback' and would like to ask if
anybody has additional ideas, experience or recommendations:

a) Do a conventional full backup of the full server

Pro: Easy to do; tape can be stored off site. Possibly can be restored
to a drive with higher capacity?
Con: System needs to boot in the first place to restore the backup.
The system files possibly can not be overwritten during normal
operation and during restore. Most likely needs a boot media (CD?)
with the proper drivers for the tape drive loaded to successfully
restore the system partition.
I'm not sure if such a restore of an AD would really work flawlessly.

b) Create a disc image

Using something like Ghost one could create an image of the system
disk and burn it to a CD.

Pro: CD can be stored off site.
Con: Image Software needs to be procured
I'm not sure if the image can be restored to a differently sized
drive.

c) Using RAID 1.

This might sound a bit odd. If the server runs RAID 1 (mirroring), one
could disconnect one of the two drives and thereby cause an artifical
hard disk error. The system would still boot from the remaining
mirrored disk. Then one could install the patches or software and
reboot. If everything goes well, the second disk is reattached and the
system mirrors the changes to the formerly disconnected disc. If there
are some errors, one would format the now flawed disk, disconnect it
and re-attach the unchanged mirror. Then the system would be rebooted
from the unchanged disk. Finally the empty disk is reconnected and the
data is mirrored to the empty disk => rollback.

Sounds complicated, but with hot swappable discs, that might be pretty
easy.

Pro: No additional hardware/software needed. No separate boot media
Con: complicated and needs thorough adherence to the step by step
procedure.

Well, that's about it. Any more ideas? Comments?

Thanks in advance

Regards

Wolfgang

--
** reply to wolfgang dot pawlinetz at chello dot at **

Mal
Thu Jan 15 08:09:52 CST 2004

A lot of the risk involved in new pathes can be worked around by in-house
testing before implementation at your customers site. We usually patch our
in-house servers the same day patches are released, & wait a few days before
applying to customers site. Our servers (last count 8, for a 6 user
network) are a fairly representative cross-section of what most of our
customers are running, chances are that a "feral" patch will show up for us
forst.

Mal Osborne
MCSE MVP Mensa

"Wolfgang Pawlinetz" <me@privacy.net> wrote in message
news:q66d00tq5c18iacv2f7vhmmh0he6gc27ct@4ax.com...
> Dear All,
>
> reading varying feedbacks about the success of patching and following
> problems with SBS2000, I was wondering how to implement sort of a
> rollback capability before patching the system (or even installing
> critical software).
>
> I am less concerned about losing data (as backups are frequently done)
> but more about the system aspects.
>
> I see several possibilities to 'rollback' and would like to ask if
> anybody has additional ideas, experience or recommendations:
>
> a) Do a conventional full backup of the full server
>
> Pro: Easy to do; tape can be stored off site. Possibly can be restored
> to a drive with higher capacity?
> Con: System needs to boot in the first place to restore the backup.
> The system files possibly can not be overwritten during normal
> operation and during restore. Most likely needs a boot media (CD?)
> with the proper drivers for the tape drive loaded to successfully
> restore the system partition.
> I'm not sure if such a restore of an AD would really work flawlessly.
>
> b) Create a disc image
>
> Using something like Ghost one could create an image of the system
> disk and burn it to a CD.
>
> Pro: CD can be stored off site.
> Con: Image Software needs to be procured
> I'm not sure if the image can be restored to a differently sized
> drive.
>
> c) Using RAID 1.
>
> This might sound a bit odd. If the server runs RAID 1 (mirroring), one
> could disconnect one of the two drives and thereby cause an artifical
> hard disk error. The system would still boot from the remaining
> mirrored disk. Then one could install the patches or software and
> reboot. If everything goes well, the second disk is reattached and the
> system mirrors the changes to the formerly disconnected disc. If there
> are some errors, one would format the now flawed disk, disconnect it
> and re-attach the unchanged mirror. Then the system would be rebooted
> from the unchanged disk. Finally the empty disk is reconnected and the
> data is mirrored to the empty disk => rollback.
>
> Sounds complicated, but with hot swappable discs, that might be pretty
> easy.
>
> Pro: No additional hardware/software needed. No separate boot media
> Con: complicated and needs thorough adherence to the step by step
> procedure.
>
> Well, that's about it. Any more ideas? Comments?
>
> Thanks in advance
>
> Regards
>
> Wolfgang
>
> --
> ** reply to wolfgang dot pawlinetz at chello dot at **

Wolfgang
Thu Jan 15 08:31:06 CST 2004

On Thu, 15 Jan 2004 22:09:52 +0800, "Mal Osborne"
<malcolmo@silverfern.com.au> wrote:

>A lot of the risk involved in new pathes can be worked around by in-house
>testing before implementation at your customers site. We usually patch our
>in-house servers the same day patches are released, & wait a few days before
>applying to customers site. Our servers (last count 8, for a 6 user
>network) are a fairly representative cross-section of what most of our
>customers are running, chances are that a "feral" patch will show up for us
>forst.

I agree, patches should be tested before being applied to production
machines. However, I made the experience, that very rarely a
production machine can be copied that closely.

In addition, there is still a residual risk, that e.g. the odd chipset
on that specific motherboard gives you problems when applying patches.

Considering this, I was just basically curious if a rollback can
simply be achieved by fully (including overwrite) restoring the system
partition of the said system. I think not. W2K or SBS will most likely
defend its system files from being overwritten during operation.

So how else can that be achieved.

Regards

Wolfgang

--
** reply to wolfgang dot pawlinetz at chello dot at **

Wolfgang
Sun Jan 18 10:00:11 CST 2004

On Thu, 15 Jan 2004 15:03:19 +0100, Wolfgang Pawlinetz
<me@privacy.net> wrote:

>Well, that's about it. Any more ideas? Comments?

None?

*sighs*

Well, I'm going to try a few thing then.

Gruß

Wolfgang

--
*
(Das ist meine Standard-Sig gezipped mit Sigzip)