I've had three attempts at restoring SBS to my new disks and three times
I've failed. Online backups are taken as per
http://www.sbs2000.info/backup.htm I've read all the back messages in this
newsgroup and searched google and as far as I can see I'm following the
restore procedure to the letter. My restore sequence is
1. Build a new windows server using SBS CD 1. I even tried making sure all
the devices were working before starting the restore.
2. Restore file system
3. Restore the system state in Directory Services Restore mode . The user
database seems to be working fine.
I've even tried restoring the file system in Directory Services Restore mode
using a file backup - no different
The newly restored SBS is not working. The main problems are;
1. Invalid entries in device manager for my network cards. (I have two -
local lan and Internet). SBS will not remember it's IP address. Every time I
try to change it, Explorer resets and stops all running desktop programs.
I've tried Q318715 and the fix from Directory Services Restore mode and that
fails. Ipconfig shows 169.XXX.XXX.XXX and not 192.168.16.2. Of course with
the wrong IP hardly anything in SBS works.
2 Various screens in the SBS console fail to start. I've restore them as per
Q294148 - that fails - its though part of the registry is missing.Other
management consoles also fail.Again part of the registry seems to be missing
The good news is I still have a working server - my old disks; and can try
any suggestions. I have Backups on DD3 tapes and as a file backup on a spare
disk. ( I mirror, do tape backups and robocopy my user data to another
disk. - Two belts and two braces!!!)
Can someone please assure me that an SBS restore is possible??? As anyone
actually done this? (Not a Windows 2000 server restore but a fully
up-to-date SBS 2000). If they have, then please tell me what am I doing
wrong.
Regards
Steve
PS I don't want to know about Drive Image or Ghost. This is also a test of
my disaster recovery procedures and so far I don't know why I own a tape
drive.
Are you wanting to change out the 30gb drives for the larger ones in the
same box, or are you trying to move to completely new hardware?
(there are quite a few issues that *could* need touching, depending . . .)
--
Les Connor
------------------
When everything else fails, the only thing left to try is . . . . again.
"Steve B" <st...@removemebrecknock.co.uk> wrote in message
news:ea0aiToLCHA.2436@tkmsftngp11...
Steve
"Les Connor" <les.c...@paddockdrilling.ca> wrote in message
news:uNB0tboLCHA.2016@tkmsftngp11...
1. Format HDD in NT box.
2. Broke mirror
3. Downgraded to basic disks.
4. Backed up Hard Drive (I use Veritas Backup Exec)
5. Reinstalled NT part of SBS onto new hard drive (using same name of
server.
6. Installed Veritas.
7 Cataloged Tapes
8 Restored. ensuring tick restore registry
9 upgraded to dynamic
10 put in second HDD , dynamic, mirror volume VOILA.
During restore it seems things finished early but veritas is very clever
Make sure you READ messages very carefully it needs a reboot to sort out
exchange.
If not using Veritas then I am stumped, just let me know which and see if I
can see any step needs to be different with your backup
"Les Connor" <les.c...@paddockdrilling.ca> wrote in message
news:uNB0tboLCHA.2016@tkmsftngp11...
(so, you only have one box, then?) Then, it shouldn't be too tricky -
something like:
Assuming: Disk 0 = mirrored drive, Disk 1 = mirror Disk 2 = new1, and Disk 3
= new2
Break mirror.
Remove Disk 1
Install Disk 2 in it's place
Format (make bootable)
Establish Mirror between original Disk 0 and Disk 2, and wait for synch.
Break Mirror, replace disk 0 with Disk 2, add disk 3.
boot up and establish new mirror Disk 2 > Disk 3.
You may or may not have to adjust the jumpers on the disks.
--
Les Connor
------------------
When everything else fails, the only thing left to try is . . . . again.
"Steve B" <st...@removemebrecknock.co.uk> wrote in message
news:#LdM9KpLCHA.1120@tkmsftngp10...
***
I'm going to first make the appeal here to Microsoft, you guys have got to
get involved here with W2K Restore and SBS 2K restore information, followed
by a tool to resolve this, even if the OS itself isn't easily fixed. A
repair of the restored file system is almost 99% probable in a matter of
minutes if someone simply makes a tool. Without this, you are leaving us
with hours of additional labor and no certainty that we have solved the
problem. We not only can't restore to a known good condition, we can only
restore to a known good data set, mostly good applications, but then require
modifications, repairs, and re-patching of the entire system from scratch in
order to have any reasoned certainty that you have a production ready
system.....and you still don't have 100% confidence because there is no tool
to tell if it's completely resolved.
I'm going to carry the water on this issue only so far, but until MS comes
up with a clarification or a tool to diagnose what we now know to be the
problem source of a major problem, we have to have the means to isolate the
impact before and after a restore.
I believe that MS needs to provide a SFNbefore tool and SFNafter tool.
The SFNbefore a backup tool should document the SFNs prior to running a
backup, and store that information in a usable text or comma delimited
format as part of the files in the backup. This tool should provide the
means to review what SFNs currently listed on the drive will be broken in a
bare metal restore.
The SFNafter restore tool should be able to read the file produced by the
before tool, and should then be able to compare what is now on the drive
that has a matching LFN, but a mismatched SFN, and report that. In addition,
it should have the ability to take the original SFNbefore tool's results,
compare which are apparently present in the restore by matched LFN names,
but then search the registry to match the original SFN to see if that
original SFN is now an orphaned entry in the registry. If it is, then either
the after tool should report that as a commented list, or should provide the
basic means or instructions to correct that.
I believe that in 95% of all cases where an SBS 2000 restore has broken
SFNs, a repair of the broken SFNs could likely be accomplished in about 2
minutes *if you knew what to change*. You wouldn't want to consider an edit
of the registry, rather, you would want to shuffle the file structure to
reestablish the original SFN assignments. It's absolutely possible to do
this. I believe that in 95% of the cases, this would be 98% effective for
all SFN breaks, and would be closer to 99.99% effective for any registered
program file entries if you had both the original SFNs/LFNs listed from
before the backup, and the resulting restore of SFNs/LFNs to compare.
The other alternative is for MS to produce the tool that forces the SFNs to
match following a restore by comparing the SFN/LFN comparison to match the
LFNs after and enforce the original SFN on them.
I am fully willing to admit that there remains a small percentage chance
that a file could remain a problem, or that a situation could be theorized
that would not work 100% of the time with the technique I have in
mind....but we would be well beyond the discussion point we are at right
now.
Right now, we have a 100% assurance that an SBS created in default install
(or anything like a typical install method) that proceeds in a 100% file by
file method backup followed by a bare metal restore will not restore ready
to run without reinstallation of several major applications.
What I propose could be done is a method that would move you from this point
forward to something like a 99% probability of a 100% effective solution in
98% of all SBS installations.
****
Okay, what do you not want to misunderstand.
Technically, I didn't find the SFN problem, it's been known, what I've done
is to document why it's a much bigger problem than anyone, anywhere I've
seen has identified it publicly. The MS documentation and the Veritas
confirmation of it has been long available, nobody ever came forward to make
the next obvious step and recognize why this is such a chronic jeopardy for
an SBS 2000 server.
1. NT Backup, Backup Exec and like products are capable of protecting the
absolutely most critical aspect of this, your data, your registry, your
domain structure, your total file structure with regard to every required
file to operate and restore a backup. Isn't this enough protection?
No. What is missing here is that certain critical application files for
programs like SQL 2000, ISA 2000 will have registry entries that don't match
the file references/locations following the restore. To resolve these issues
by the best documented method Microsoft currently identifies, you would need
to reinstall each of the applications involved. Once that is done, you
server would be again in the condition that all applications are functional,
but you next need to reinstall all Service Packs, and security patches that
were previously applied to ensure that the system is completely returned to
a normal operational condition.
The result of this is almost 99% likely to be 100% functional as the server
was in the condition that the backup was made. There's a key point, however.
The server will not have been restored to a known good condition.
2. Can an SBS 2000 Server be restored from backup with 100% certainty?
Yes. Use a drive imaging product that can backup and restore the entire
partition table, therefore preserve the SFNs.
3. Is it possible to restore an SBS 2000 to a "known good condition"
using only NT Backup, Backup Exec, or any other file by file method data
backup product to restore the server to a bare-metal restore?
No. This is pretty certain. You cannot get to a previously configured, known
good condition by use of a file by file restore.
4. Is it possible to restore an SBS 2000 to a "known good condition"
using any method?
Yes. Partition imaging products can provide this capability.
5. Is it possible to restore an SBS 2000 to a known good condition if I
restore over the existing file structure, rather than to a bare metal
restore?
Generally, yes, this is going to work. The caveat is that if the files
structure on the drive includes the critical folders, and the critical files
already, but either these files are corrupted, or the configuration is
invalid in some manner, you can restore an earlier backup, overwrite those
files, and the files will be returned to their earlier condition without the
SFN problem entering the picture.
However, if you have an existing files structure, then you intentionally
delete a folder such as the SQL 2000 application folder, then restore the
original SQL 2000 folder from tape but where there are not the original
files still present to overwrite, you result is unpredictable for stating a
general rule. The outcome is predictable, but the conditions would need to
be specifically known in order to know if the restore will produce the same
SFNs, or different ones as the restore takes place.
6. If you can restore to overwrite an existing installation, is it
possible then to restore an SBS 2000 from bare metal to a "known good
condition" using a combination of an older partition level backup as a
slightly dated "baseline", followed by a restore of recent file by file
backup?
Yes, if you have not revised any of the application programs stored in the
registry, this almost certainly would work.
To implement this strategy, you would need to periodically update your
partition image in order to ensure that all the critical folders and files
that would be impacted by a bare metal restore are included in the most
recent partition backup.
For instance, in most cases, a new Security Patch hotfix would not impact
the conditions, though it could in some occasions. It would be possible to
perform a before and after test to determine this if you had the time and
skillful knowledge to do the testing. Ideally, a diagnostic tool could be
created to automate this process of evaluation.
7. Can an SBS 2000 Server be restored from backup with 100% certainty if
you don't use a partition image program?
Tricky question, I'll answer it this way.
I personally do not fear that all of the customers I currently protect with
only Backup Exec are at some tragic risk I can't solve, or that of permanent
losses because of this will result. I recognize that the recovery/rebuild
process is an effective
What concerns me is:
(a) that for a company that performs a 100% backup nightly that takes 4 hrs
to run using NT Backup/Backup Exec or the like, the recovery time on a bare
metal restore is going to be something that could be approaching 7-9 hours
if you are well prepared, skilled in SBS installation, repair, and security
patching.
(b) a restore from tape of a file by file backup doesn't put me at a known
good historical point with a 100% ready to run server, just in the same
condition it was in on the date the tape ran to create the backup.
(c) using file by file backup/restore provides me a means to an end, but
it's not the end, it's the middle. I must have more tools, more time, and
more experience that is specific to this computer in order to restore it. In
essence, comparing what the situation was with an SBS 4.5, it was extremely
likely that if I had a server with the same motherboard as the original and
one complete tape, a tape restore was almost 100% effective as the entire
need for a truly high confidence disaster recovery preparation. I'm not
anywhere close now due primarily to the lack of information, lack of
diagnostic tools, and the extended time required to perform such a recovery.
(d) while most any SBS is going to have a core set of applications that are
almost always broken by this restore process, each and ever computer has the
potential to have "just a few more" unique breaks that can only be diagnosed
with extreme skill and familiarity with the normal operations of the
computer, and the nature of this SFN problem.
(e) the idea that an SBS server, which is intended to represent a product
value for ease of deployment, support and maintenance will instead represent
a huge technical challenge to maintain until disaster recovery and patching
tools address our needs for reliable patch recovery and disaster recovery
scenarios.
8. What do I need to do to ensure that my Active Directory information is
protected and will restore from a backup using NT Backup, Backup Exec, or
the like?
You need to ensure that your server is running Windows 2000 SP2 or higher,
and you need to perform a System State backup at a minimum, or include a
System State backup as part of your normal backup operations.
9. What do I need to do to ensure that my Exchange Server information is
protected and will restore from a backup using NT Backup, Backup Exec, or
the like?
There is no direct implication here for the SFN problem with Exchange,
though it too is susceptible to a failed Exchange 2000 applications restore
if the SFN path for the "Exchsrvr" folder tree is impacted by the restore
process. However, in the default installation, if you install SBS 2000 in a
default mode, and then prepare the normal backups, you should have no unique
issues to perform a restore. If for some reason a restore from backup
resulted in an SFN problem, you would need to simply refresh (reinstall) the
Exchange 2000 installation again, including the POP3 Connector (even if you
don't use it), plus the SBS Administrative Console, followed by all
previously installed Service Packs for Windows 2000 and Exchange 2000. You
should also reinstall any security hotfixes for Exchange at that point, then
perform the normal database roll-back/installation process if that wasn't
done already during the process identified above.
What follows is a listing of information related to Exchange restore issues
that are not really new, not really associated with the SFN issues, just put
here for completeness on this topic:
(a) You need to ensure that you are routinely performing an online backup
with an Exchange aware backup program (like NT Backup or Backup Exec which
have Exchange support features)
(b) You need to be running Exchange SP1 at a minimum, preferably SP2.
(c) You need to ensure that the Exchange Server installation you intend
to restore your backup to has the same Service Pack level as the one at the
time of the backup. You cannot restore an Exchange 2000 SP1 backup to an
Exchange 2000 SP2 condition server, or vice-versa.
(d) You need to ensure you have the same condition for Exchange Instant
Messaging established for the server. For both the Exchange Server, and the
databases you are restoring, both must have or not have EIM installed.
(e) You can use an offline backup of Exchange database files to recover
the databases to the same server, with the same Organization Name and Server
name.
(f) You can recover the contents of an Exchange 2000 database if you use
the Exmerge utility, and you can do this on a server other than the original
SBS server provided it is properly configured. It isn't necessary to recover
the Exchange databases for the Active Directory SAM to match the original,
but it is convenient. What is critical is the naming of the Site, Server and
Organization names. Beyond that, the SAM can be different, but doing so may
lead to some added complications in the recovery process. It becomes a more
advanced recovery process.
10. Is something wrong with SBS 2000 that prevents the restore of a
backup by normal backup programs like NT Backup or Backup Exec from
restoring the program correctly.
No, SBS is not defective. The issue is not specific to SBS, the issue is
native to all Windows 2000 based systems. It's also present in Windows XP,
Windows NT, Windows ME, Windows 98, Windows 95, as far as I know, though
I've not tested them all. What I know is that
It would be news and a surprise to me if the Active Directory restore
process that retains the domain information were at all impacted by the SFN
problem I've documented.
11. Why can't I restore my Active Directory domain information from the
Directory Services Recovery Mode boot method using Veritas Backup Exec?
You can, but you will have to modify the Backup Exec services to ensure that
they run from a local service account, rather than a domain user account
which is the normal way they work. This is because in the DSRM mode, the
domain user account is not going to authenticate, but the local system
account will, and does have the required permissions to perform a local
restore.
You may wonder why Veritas didn't simply use a local service account
already? This is explain best by the observation that Veritas provides
remote backup and restore operations between computers, and a local service
account at one machine would not have access to the required permissions at
another machine. Instead, a domain user account is established as a member
of the local service accounts at each station, and therefore all the
required services start from this commonly assigned user account acting as a
member of the local services at each respective machine.
12. It sounds like partition level backups are the only safe way to go in
backing up the server, is that right?
No. A partition level backup would make a very complicated recovery media in
many conditions. For instance, you would not be able to recover an SBS
Server with an Active Directory SAM problem by using only a partition backup
unless you are willing to restore the entire server, all applications, many
settings, and quite a lot of complexities along with it. In fact, it would
almost always be difficult if not impossible to restore your server without
also losing significant amounts of data using a partition restore. You are
far better off to have a System State backup, not a partition image, as your
protection against an Active Directory or SAM corruption problem as well as
for almost any Registry repair other than a 100% rollback of a machine to a
earlier point in time. Look at the next question.
13. Why is a partition level backup not really ideal for a recovery of
the registry, SAM or Active Directory?
With little exception, partition images generally are not adequate for
selectively restoring "brick by brick" with individual files. Most partition
backups require restoring the entire partition. That means that they
overwrite the entire partition effectively wiping it out in the process of
putting the restored information. You won't have a combination of the file,
you have only the files in the partition image you restore.
Therefore, to restore the machine to a current condition, where all you need
is the registry or Active Directory, you would probably need to restore
everything to a bare drive, then configure that drive in a machine to boot
it, then make a normal System State backup, then shutdown again. From there,
again reboot on the normal production machine in the proper manner to
restore the System State as you required.
The only other alternative would be to devise a method to do a file by file
backup of all the files newer than the ones that are in the partition
backup, then restore the partition image, the restore the file by file
backup of the most recent files, but being certain not to overwrite the
critical files you were actually trying to roll back!
14. At this moment, what is likely to be my most certain manner to
protect my SBS server?
+ Prepare an Emergency Repair Disk (ERD disk) including the option to update
a repair folder, and repeat this process after every new program install,
service pack, hotfix, and major change in your Active Directory
configuration.
+ Routinely perform a System State backup to external media like tape, CDR,
or a hard drive that doesn't operate in the machine daily, rather sits on a
shelf.
+ Prepare a 100% partition image of the system drive, any drive that
includes installed applications. You probably would prefer to make an image
of all partitions just to keep it simple to maintain. Update your partition
image copy following the installation of any major application that is
critical to the operations of your server or network, or following major
changes such as Service Pack updates. You might want to repeat following the
addition of new Hotfixes, but this becomes a discretionary issue because you
could install the hotfixes after a restore and still achieve the same
results, even if the SFNs had changed on related files.
+ Keep all of the original distribution CDs, drivers, service packs and
hotfixes in a locally accessible and external media. You may need these
before you have the ability to restore them from tape or an image.
+ Maintain a record of all Service Pack updated, Hotfix updates, and
application program installations after you have your SBS in service,
recording the installation date, and the sequence of installation. This is
not a critical piece of information, it's a valuable piece of information,
just a reference and good practice.
+ Maintain a record of the entire contents of all partitions which includes
the LFNs and SFNs. This can be done with the following command:
Dir [C:\] /s /ahs /x > filelist for C.txt
You can repeat the command for other drive letters, the illustration assumes
you execute that command from the root of C:, and the text file indicated
will be created in that same folder with the name indicated. That command
will "walk" the folder structure and all subfolders to display each folder's
contents by both SFN and LFN.
While this is not an elegant record, it's a useful one. This information
allow would allow a skilled individual to determine what SFNs have been
broken following a restore to bare metal. This doesn't provide the means to
quickly accomplish either diagnostic process or the correction, however it
does contain the minimum required information to do either.
+ Prepare a boot floppy, and keep it on hand in case you should need to
diagnose a boot problem following a partition restore which fails to boot as
expected. If you find it necessary to alter your boot floppy to evaluate
different settings, recover a copy of the original boot.ini file contents
before making changes.
+ If you are not in the position to routinely make a partition level backup
of your SBS server, at the very least you should attempt to keep one
partition level backup from some point in time, even if it isn't updated
form months on end. It is in fact better than nothing.
+ If you are not in the position to retain even one partition level backup
of your SBS server, you should attempt at some time to make a clean
installation of Windows 2000 on the same or similar hardware configuration,
and retain this permanently. For instance, a dealer may not be in the
position to justify the expense and effort required to each and every
customer for providing a unique drive image for their server. However, if
you ever need to do a bare metal restore of a server, the very first step
will be either to restore a previous image of the same server, or to prepare
a clean installation of Windows 2000. These are the only common methods of
recovery.
Therefore, if you can't maintain an image of the SBS installation, an image
of a basic Windows 2000 Server install is better than nothing. At least you
are possibly 30-45 minutes ahead of the recovery process by simply doing the
restore of this.
Alternatively, the Windows 2000 recovery console has it's uses, but a
parallel boot of a machine is always an effective diagnostic tool. If you
can maintain a basic Windows 2000 image (like this one suggested) and a
spare drive to restore the image to as the destination, you at least could
boot the system from this restored image to either inspect the production
drives, or to begin the rebuild and restore of the SBS 2000 itself. You can
either continue the SBS 2000 installation directly on that base install, or
you can restore file by file from tape, or you can inspect the production
drive. It's quite useful.
"Steve B" <st...@removemebrecknock.co.uk> wrote in message
news:ea0aiToLCHA.2436@tkmsftngp11...
--
Steve Osmolinski
"Jeff Middleton [SBS-MVP]" <je...@cfisolutions.com> wrote in message
news:OMS55kpLCHA.2372@tkmsftngp11...
Further to my previous post I must add SQL was not installed and before
backup done hfnetchk run to ensure all updates / patches applied. Also
chkdsk run to verify integrity.
"Jeff Middleton [SBS-MVP]" <je...@cfisolutions.com> wrote in message
news:OMS55kpLCHA.2372@tkmsftngp11...
OK, I see where you're coming from now. Call me thick.
--
Les Connor
------------------
When everything else fails, the only thing left to try is . . . . again.
"Les Connor" <les.c...@paddockdrilling.ca> wrote in message
news:O9BJzgpLCHA.2688@tkmsftngp11...
But in case anyone get's confused, Jeff is persuing a fundamental .. er..
flaw .. in the OS that needs addressing. And, while keeping us informed,
he's persuing it on his usual highly technical level, and in collaboration
with those that are in a position to actually do something about it.
But for Steve B - (who may have discovered this .. er .. flaw) who only
wants to swap his IDE disks, he doesn't actually have to do a bare metal
restore to get that job done.
So anything below Jeff's post is a branch of the thread that probably
demands a dedicated newsgroup, never mind thread :-).
--
Les Connor
------------------
When everything else fails, the only thing left to try is . . . . again.
"Steve Osmolinski" <st...@ccclabs.com> wrote in message
news:ujebmun...@corp.supernews.com...
we've been playing this game recently also (on a test box). I'm
interested, are your two NICs similar ? Are the NICs using Microsoft drivers
or drivers supplied by the manufacturer ?
We have decided that a little preparation is required. Before backup:
1) Add the MSLoopback adapter. This can stay permanently on the machine,
just treat it as though it is a DMZ. Having this installed means that during
restore you have at least one functional NIC for services to bind to. After
DS restore we are experiencing the same problem as you re NICs, uninstalling
and re-installing the NICs fixes it. We're using a mobo with two onboard
Intel pro's and the drivers are getting linked to the wrong adapters. One
NIC is pro100+, the other is pro100VE.
2) copy the ISA gkdb.mdb to another location. This means the file is not in
use and can be backed up. The file is normally in use during backup so is
missing from the restore, this breaks the H323 gateway.
3) There are a number of .DAT files in exchange\mtadata, the missing ones
can be recovered from CD, in the backenv directory. Do not replace the
existing copies. There's a KB article on this
<snip>
> 1. Invalid entries in device manager for my network cards. (I have two -
> local lan and Internet). SBS will not remember it's IP address. Every time
I
> try to change it, Explorer resets and stops all running desktop programs.
> I've tried Q318715 and the fix from Directory Services Restore mode and
that
> fails. Ipconfig shows 169.XXX.XXX.XXX and not 192.168.16.2. Of course with
> the wrong IP hardly anything in SBS works.
>
> 2 Various screens in the SBS console fail to start. I've restore them as
per
> Q294148 - that fails - its though part of the registry is missing.Other
> management consoles also fail.Again part of the registry seems to be
missing
we're not seeing this (2)
> The good news is I still have a working server - my old disks; and can try
> any suggestions. I have Backups on DD3 tapes and as a file backup on a
spare
> disk. ( I mirror, do tape backups and robocopy my user data to another
> disk. - Two belts and two braces!!!)
>
> Can someone please assure me that an SBS restore is possible??? As anyone
> actually done this? (Not a Windows 2000 server restore but a fully
> up-to-date SBS 2000). If they have, then please tell me what am I doing
> wrong.
we're succeeding, but this is a clean install on a test box. Next step is to
remove drive0 (first mirror) from my Lounge Area Network and see if I can
get the system back,,, probably this weekend.
I'm not saying it doesn't work (although IMHO it doesn't) and to be fair the
data files are backed up OK. Exchange data, well - depends - might be able
to recover this, but after a re-install of the OS (which seems mandatory)
I've not tried. Personal Folders are better in some respects - at least the
PST's can easily be salvaged from the tape!
If there is a way, MS should tell us how it can be done - but ticking the
approved boxes is not the way, for sure.
If it is a data backup only, well that's fair enough, at least we know what
the score is, but it's easier & cheaper to use a batch file, xcopy and an
IDE HDD than a £1000 DLT with £500 media pool.
Either way, I think we should be told. By Microsoft.
Graham
Phew.... extensive post Jeff, still re-reading that. You also believe it
doesn't work, I think?
"Mick Malloy" <n...@public.groups> wrote in message
news:uWCBpmqLCHA.2324@tkmsftngp09...
Mal Osborne
MCSE MVP Mensa
>.
>
Del
Steve B <st...@removemebrecknock.co.uk> wrote in message
news:ea0aiToLCHA.2436@tkmsftngp11...
"Del Earnheart [SBS Newbie]" <del.ea...@mindspring.com> wrote in message
news:#pGdDktLCHA.2588@tkmsftngp08...
Regards,
Richard
"Steve B" <st...@removemebrecknock.co.uk> wrote in message
news:ea0aiToLCHA.2436@tkmsftngp11...
If you have restored by using powerquests drive image does
the software resize the new partions or does it split the
drive for you. Also when you mentioned that you save the
data onto cd's does that mean the software has the spanned
facility because after all the main c: drive could up to
4Gb.
Thanks
TIM
>.
>
I've said it before, the Windows family (including .NET, Longhorn, Blacomb
etc ) will be toy operating systems until they incorporate an industrial
strength Backup solution. Backup is NOT a bolt on, it must be a fundamental
part of the OS. I worked on Disaster Recovery plans for a number of large
AS/400 systems (up to 500 users) in the 90s. With a bit of effort you could
get to the point where a bare metal box, a tape and your 10 pages of
instructions was all that was needed to do a complete restore.
Now we got all this garbage with partitioning and CDs and bolt on products
and it just isn't acceptable.
And the worst thing is I reckon that this could take 10 or more years to
resolve. Microsoft accepted the limitations of the directory structure in
the early 90s. The solution is coming in three stages (W2K-AD, XP-SP1/.Net
and Longhorn(we hope)) - delivered between 2000 and 2005. Blackcomb
addresses other functional and secutity issues and will not appear until
2006. On this cycle, even if Microsoft accepted the dire situation regarding
protection of its clients most valuable asset (data and system
infrastructure) it would probably take 10 years to engineer the changes.
Especially in the quality consious "Trusted Computer" era.
Scary and depressing.
jdh
"Jeff Middleton [SBS-MVP]" <je...@cfisolutions.com> wrote in message
news:OMS55kpLCHA.2372@tkmsftngp11...
You may imagine that the day it hit me first what I was coming upon,
realizing the scope of what it means....was more than a bit depressing. I
started thinking of the millions of computers impacted by this.
I've been talking around some "solution" concepts without really landing on
them in explicit detail because I don't have access to the core level
documentation MS has internally. It's sort of ironic that I actually know
how to quickly fix every instance of SFN problem I've run across that
originates as a post WinNT 3.5 file/folder instance. (Meaning, if the
computer was installed new or upgraded from anything WinNT 3.5 or later NT
Family, and doesn't contain registered applications from outside that
pre-existing realm, this can be fixed in a restore process without a lot of
pain.)
For most of us, SBS in particular, that means 100% solution and little pain
to deal with it in a disaster recovery scenario. The problem is this problem
drives very deep into the OS and has implication most people still are
probably not grasping from what I've already posted here.
At some point, any software code design approaches an inability to handle
situations that are highly improbable. What makes this one so remarkable is
that it's no improbable, it's a guaranteed issue in unbelievable scale of
distribution by MS.
So, on the one hand I feel like I'm standing here shouting about a plague,
but I have a measure of cure to offer everyone I know, but I don't have the
means to address it that doesn't instantly shift the burden of a tragically
deep flaw in MS product design that I simply cannot undertake supporting
independently.
"jdh" <green...@hotmail.com> wrote in message
news:uNCtkRzLCHA.1604@tkmsftngp09...
"Note: PowerQuest VolumeManager supports basic disks only in Windows 2000.
Dynamic disks (LDM) are not supported at this time."
So the Drive Image route is a non starter for me
The only way to revert a Dynamic disk to a Basic disk is to remove all
allocated drives and therefore lose all your data.
Steve B
"Richard Wagstaff" <rwag...@lawrence.co.xxx.uk> wrote in message
news:OQGNngvLCHA.2508@tkmsftngp08...
Same thing for SBS; except it failed. You confirmed my opinion that a Full
restore of SBS 2000, even to the same hardware, is NOT Possible by your
average competent IT support person. By competent, I mean someone who reads
the instructions. I wasn't aware of the Small Filenames issue but now I know
some of what is going wrong. I don't think it's the only problem. I didn't
say in my first post that I am only using the Backup program as supplied by
Microsoft and no third party products.
Has everyone realised what I just wrote. I will shout it again :-
A FULL RESTORE, TO A WORKING CONDITION, OF SBS 2000 USING ONLY THE
MICROSOFT SUPPLIED BACKUP SOFTWARE IS NOT POSSIBLE!
How will I upgrade my disks? By doing a full install which is exactly what I
did June 2001 when I changed motherboards and couldn't get SBS working then.
I was trying to avoid the hassle of 'Service packing' and patching all over
again, and the hours pouring over ISA, getting it to my level of security
while allowing the things in and out that I wanted.
I expect Microsoft has never admitted this. Failure to restore is always the
fault of some incompetent IT person and nothing to do with their OS. Or
"what do you expect if you change the hardware"; which is the most likely
disaster recovery situation.
Thanks again Jeff for convincing me that I'm not the only incompetent IT
person out there.........No I definately don't mean you.
I wonder how many more millions of W2K's and XP's will MS sell knowing the
situation? Does anyone in that organisation have a conscience?
Steve B
<Big Snip>
Ghost claims to support a "form" of Dynamic Disk cloning. They say you can
restore the created image a basic disk and then use Win2K to change it back
to a dynamic disk. Any comments?
http://service2.symantec.com/SUPPORT/ghost.nsf/docid/2000062209523525
---------------------------
Partition-to-Image
Ghost supports creating a partition image of a Dynamic Disk for both Simple
Volumes and Mirrored Volumes and restoring that partition to a Basic Disk.
Ghost does not support restoring a partition to a Dynamic Disk.
To clone a Simple or Mirrored Volume, run Ghost normally. Ghost will detect
the Simple and Mirrored Volumes and will save the contents of the volume as
a nonDynamic partition. After restoring the image to a Basic Disk, use the
Windows 2000/XP Disk Management MMC utility to convert the partition to a
Simple or Mirrored Volume.
NOTE: Because Ghost cannot restore a partition image to a Dynamic Disk, you
cannot use this process to convert a Dynamic Disk to a Basic Disk. If you
want to restore a partition image to a Dynamic Disk, you must first convert
the disk to a Basic Disk.
---------------------------
Merv
=================
"Steve B" <st...@removemebrecknock.co.uk> wrote in message
news:#v6FXO1LCHA.2036@tkmsftngp09...
SBS 2000 is a 'mission critical' application which, almost by definition, is
the life blood of a small business with up to 50 employees.
Some procedure for restoring a fully working system must be made available.
Microsoft engineers need to actually try this and document how it is
possible.
"Steve B" <st...@removemebrecknock.co.uk> wrote in message
news:#ZF8x21LCHA.2436@tkmsftngp11...
Steve B
"Merv Porter" <mwp...@hotmail.com> wrote in message
news:eup3AE2LCHA.2520@tkmsftngp08...
Jan and I have done this IMPOSSIBLE thing SEVERAL TIMES this week.
I agreee with you and almost all of your points and conclusions.
However there are a couple of issues in relation to the "tool". My
understanding is that the problems arise due to the storage of SFNs in the
registry by some applications, particularly OLE, the SBS consoles and I
think ISA. MS needs to fix these anyway, this is really just a serious
symptom of bad programming.
However unless I am missing something (quite likely) a tool only needs to
read through the registry looking for SFN references, and use the old/new
list you have suggested and put the new SFN in the registry.
The other issue that Steve B encountered and so did I when I did exactly
this process myself is strange things happening to the NICs when you do a
bare metal reinstall of w2k with or without SBS followed by a restore of
System State. I had the system in a terrible state. There were hidden NICs,
and all sorts of things. This appears to have nothing to do with the SFN/LFN
issue.
Regards
Daryl
"Jeff Middleton [SBS-MVP]" <je...@cfisolutions.com> wrote in message
news:OzFKEO0LCHA.2512@tkmsftngp10...
"Steve B" <st...@removemebrecknock.co.uk> wrote in message
news:Onc8cK2LCHA.2004@tkmsftngp10...
Steve B
"Mick Malloy" <n...@public.groups> wrote in message
news:eRCjWz2LCHA.2248@tkmsftngp10...
Thanks. Ghost v7.5 does indeed very successfully clone a dynamic disk to a
basic disk if you use a disk to disk copy.
Steve B
"Merv Porter" <mwp...@hotmail.com> wrote in message
news:eup3AE2LCHA.2520@tkmsftngp08...
I think you may not have gotten the complete information correct on the
Powerquest site. I believe that several of their products will image a
dynamic disk partition, but perhaps the one you pointed out doesn't. I went
to the site to search their KBs and found a number of references that
indicated tshoots on problems following an image of a dynamic disk which
were implying how to resolve an issue, and basically assuming that imaging
dynamic disk was an acceptable practice.
"Steve B" <st...@removemebrecknock.co.uk> wrote in message
news:#WCGlbAMCHA.2488@tkmsftngp09...
I use Ghost 7.5 and this can resize partitions so that you could
turn a smaller partition into a larger. I have done this many times
with SCSI disks. Should work with IDE disks also. No need to use
Partition Magic. In Ghost 7.5 use a disk to disk copy, with
Options/Image-Tape/Image Boot selected. If you are going to turn this
disk into a dynamic disk, don't use the entire disk space -leave 8MB
free at the end. The above option gives you the choice of being able
to resize the destination partiton. The destination drive will need
to be marked active. I often use fdisk to accomplish this, or use
Disk Manager in W2k.
One warning using Ghost with W2k, once you have duplicated a disk
shut down the computer and unplug the duplicate drive. If you reboot
and both drives are online, undesirable things happen. When you
reboot run the source or destination drive but not both.
Rob Muir
"Daryl Maunder" <dmau...@midnightoil.com.au.nospam> wrote in message news:<#oR0uN3LCHA.1608@tkmsftngp09>...
To restore, we initially install vanilla W2KS, standalone mode. Actually, as
we've been doing this a few times we ghosted a clean W2KS install, all this
does is save time though. Once we have W2KS on the box, a restore is
performed. This is done in Directory Services Restore mode and includes all
of 'C' and the system state, exchange cannot be restored at this point
because it is not running. The restore options are adjusted to allow
overwrite of all files and for restored data to be primary replica (but I
think this last is unneccessary for us at this moment, no replicated data
sets TTBOMK)
I've documented elsewhere in the thread the three areas we are finding
require attention. NIC's (our test box has two), ISA & Exch.
When these are addressed Exchange can be restored (as it will now be
running, but with no store). Taking normal steps for an Exch in this
condition.
End of story. We're not getting issues from SFN's. We've succeded in both
'basic' and 'dynamic' disk scenarios.
The test system is a default install of SBS2K with a couple of users created
and a few emails with attachements in exch. It is, however, a simple
scenario. I will probably today take down my Lounge Area Server in order to
test a slightly more complex box (mind you, I'm putting the mirror on the
shelf before I start)
"Steve B" <st...@removemebrecknock.co.uk> wrote in message
news:ulzPRS9LCHA.1608@tkmsftngp09...
I've today taken the boot drive out the Longe Area Network SBS and booted
off the mirror. A third drive was available and was used to perform a backup
to file using NT Backup. At this time the original boot drive was
disconnected (fallback), the mirror was acting as boot drive after being
changed to primary IDE master (previously on secondary IDE). The spare drive
shows as 'E" and is on secondary IDE as master.
When the backup completed I deleted the boot partition, installed W2KS and
proceeded to restore SBS, starting with Directory Services.
The 8029 external NIC was detected correctly, the 8139 internal needed
reinstall.
I now have the console problem, later.
Other than fiddling with Exchange she's back up fairly painlessly.
I really appreciate your reply.
Do I understand correctly that your sequence for a Full Restore of SBS2000
is as follows
Pre-restore -
1. add a loopback adaptor in networking
2. copy the ISA gkdb.mdb to another location.
> 3) There are a number of .DAT files in exchange\mtadata, the missing
ones
> can be recovered from CD, in the backenv directory. Do not replace the
> existing copies. There's a KB article on this,
I'm not sure of your preparation for exchange. My understanding is you do
not do anything pre-backup. Only recover missing files from the exchange
distribution post restore??? I didn't get as far as evening trying to
recover exchange. SBS was too broken.
3. Perform backups as per http://www.sbs2000.info/backup.htm
The Restore process
1. On a new drive - Install vanilla W2K Server i.e. CD1 of the SBS
distribution set
2. Boot into Directory Services Restore mode and restore the system state
first.
3. While still in Directory Services Restore mode restore Drive C: (or do
you allow a reboot first)
4. Boot normally remove and reinstall your NIC drivers
I'm also using an Intel motherboard with a single onboard PRO/100 VE. I also
have a D-Link DFE for my cable modem connection. Reinstalling the drivers
alone does not fix the networking issues on my system. I cannot remove the
NIC's as it wont let me "device is required to allow the system to boot". It
does this even in Directory Services Restore mode.Q318715 tells you to
remove TCP/IP while in Directory Services Restore mode, but it won't do this
either. I've never tried this with a loop back adapter installed.
5. Reboot and restore Exchange and the missing files in exchange\mtadata
from the exchange distribution CD
6. Copy ISA gkdb.mdb back to \Program Files\Microsoft ISA Server.
(Perhaps this should be done after step 3 before the reboot.)
7 . Reboot and you have a completely full functional SBS2000?
Sorry to spell this out but if this works I suspect you are the one of the
few people in the world that has sorted out how to do this.
If you can go over the above procedure and confirm the steps, I will give it
another try.
Thanks again for your help
Steve
<Snip>
Problem Description:
Does PartitionMagic support Windows 2000 dynamic drives?
Solution: Does PartitionMagic support Windows 2000 dynamic drives?
No version of PartitionMagic supports Windows 2000 dynamic drives at this
time.*
*As of August 2001, PartitionMagic is at version 7.0.
They should update their website if this is not correct.
They have probably moved on from V7.5 but hey I was still much more
interested in a restore solution than a drive clone solution. I really don't
care if I can ghost or drive image my SBS as this is not really feasible for
day-to-day backups.
Having said that, perhaps it is. You said in a previous post it was the only
sure way of getting a system back. Drive Image/Ghost, ( I know Ghosts works
fine) then incremental tape backups. Now if I went down the USB route I
don't need to have Backup disks permanently attached, and I don't need to
dismantle my server every time I create an image. Some downtime out of hours
while I did the clone wouldn't be too bad. IDE hard disks are cheap; MB per
MB not much more expensive as DDS4 tapes and certainly cheaper than DLT's.
( I don't have either). - Food for thought - thanks Jeff.
Steve B
"Jeff Middleton [SBS-MVP]" <je...@cfisolutions.com> wrote in message
news:eau8lzAMCHA.1928@tkmsftngp13...
> Steve,
>
> I think you may not have gotten the complete information correct on the
> Powerquest site. I believe that several of their products will image a
> dynamic disk partition, but perhaps the one you pointed out doesn't. I
went
> to the site to search their KBs and found a number of references that
> indicated tshoots on problems following an image of a dynamic disk which
> were implying how to resolve an issue, and basically assuming that imaging
> dynamic disk was an acceptable practice.
>
>
> "Steve B" <st...@removemebrecknock.co.uk> wrote in message
> news:#WCGlbAMCHA.2488@tkmsftngp09...
> > Merv,
> >
> > Thanks. Ghost v7.5 does indeed very successfully clone a dynamic disk to
a
> > basic disk if you use a disk to disk copy.
> >
> > Steve B
> >
<Snip>
Partition Magic and Drive Image are two separate things (I think you got
them mixed up).
Cheers
Mark
"Steve B" <st...@removemebrecknock.co.uk> wrote in message
news:udI4PrKMCHA.1728@tkmsftngp09...
not required, but probably helpful. The main thing this avoids is bringing
up the box without any interfaces. This isn't actually the scenario's I've
seen. In both scenarios (test box and LoungeAN) the interfaces have existed,
to a degree, and the box doesn't go into the PITIFULLY CONFUSED MODE we have
previously seen when an SBS comes up with no interfaces. (three hours to
boot, and when it comes up services which actually manage to start have 1)
bound to wrong interfaces, 2) had, for some reason, their dependencies
change. If you are ever looking at an SBS saying 'Preparing Network
Connections' for an hour or so you may assume the interfaces haven't come up
correctly and it's time to loosen the tie and fill the coffee urn.
> 2. copy the ISA gkdb.mdb to another location.
I don't know how 'volatile' this file is. Funnily, though ntbackup cannot
back it up while it is in use, copy seems to have no problem with it. We use
a scheduled server_backup.cmd to perform backup, gonna add 'copy "c:\program
files\Microsoft ISA Server\gkdb.mdp" "c:\program files\Microsoft ISA
Server\backup\gkdb.mdp"' to the script.
>
> > 3) There are a number of .DAT files in exchange\mtadata, the missing
> ones
> > can be recovered from CD, in the backenv directory. Do not replace
the
> > existing copies. There's a KB article on this,
>
> I'm not sure of your preparation for exchange. My understanding is you do
> not do anything pre-backup. Only recover missing files from the exchange
> distribution post restore??? I didn't get as far as evening trying to
> recover exchange. SBS was too broken.
Actually, I'm thinking it's best to copy the contents of the 'bootenv' (not
backenv) directory off the CD to either a subdir of exchsrvr or a 'maint'
area.
>
> 3. Perform backups as per http://www.sbs2000.info/backup.htm
our command is similar to Mariette's, does some additional stuff to copy
logs to c:\backup\logs, and after this mucking around, probably some other
copies.
>
> The Restore process
>
> 1. On a new drive - Install vanilla W2K Server i.e. CD1 of the SBS
> distribution set
We're actually using a _real_ vanilla W2KS, shouldn't be an issue for the DS
restore part of the equation.
> 2. Boot into Directory Services Restore mode and restore the system
state
> first.
> 3. While still in Directory Services Restore mode restore Drive C: (or
do
> you allow a reboot first)
I am performing both operations while in DSR mode from the one run of
ntbackup. (select 'c:' and 'systemstate', not 'exchange')
> 4. Boot normally remove and reinstall your NIC drivers
>
> I'm also using an Intel motherboard with a single onboard PRO/100 VE. I
also
> have a D-Link DFE for my cable modem connection. Reinstalling the drivers
> alone does not fix the networking issues on my system. I cannot remove the
> NIC's as it wont let me "device is required to allow the system to boot".
It
> does this even in Directory Services Restore mode.Q318715 tells you to
> remove TCP/IP while in Directory Services Restore mode, but it won't do
this
> either. I've never tried this with a loop back adapter installed.
When the "device is required to allow the system to boot" message appears,
installing the loopback adapter, disabling the 'phantom' NIC (if it allows)
and rebooting should allow you to remove and reinstall the NIC. I've seen
scenarios where this has failed, adding the NIC and then reboot/disable
'phantom' (it may come up as disabled, despite the message about "device is
required to allow the system to boot")/ reboot/ remove 'phantom') [I think,
one problem we have seen is that under consistent test conditions we have
seen varying behaviour,,, not sure what happened when we got this scenario]
>
> 5. Reboot and restore Exchange and the missing files in
exchange\mtadata
> from the exchange distribution CD
> 6. Copy ISA gkdb.mdb back to \Program Files\Microsoft ISA Server.
> (Perhaps this should be done after step 3 before the reboot.)
can be done at any time after file restore of \Program Files\Microsoft ISA
Server.
> 7 . Reboot and you have a completely full functional SBS2000?
I cheated. I thought about the benefits vs cost of restoring my console late
Sunday evening. Caution won out so I reverted to my mirror. I'll probably be
going through it all again next weekend.
Steve
"Mark" <msz...@nospam.hotmail.com> wrote in message
news:u1oCBDRMCHA.2512@tkmsftngp10...
I take it the answer is no, then?
So, a fully working up-to-date SBS2000 system (maybe the patches & SP's have
removed the ability from first release of the product, or maybe, likely, it
has never worked) cannot be restored, from tape or file, made using MSBackup
with the recommended procedure (in this NG,) or by clicking on the "Backup
Everything on my Computer" button.
Anybody disagree?
<silence>
OK, lets move on....
Next question.... will any other non-MS backup software allow this to be
done? We're talking 'disaster recovery' here, not cloning images to bigger
hard disks from a working system. I guess at this point (many systems will
be quite fault tolerant and may never need to be 'recovered' but the
scenarios I have mentioned above WILL occur sometimes) we have to assume a
very similar hardware platform can be obtained.
What's the best option?
--
Jerry Moore, MCSE/MCP+I/A+
Un-employed since Sept18, 2001
My DREAM is to work for MICROSOFT, What's yours? :)
Bit Slinger for Hire, SBS is my home :)
"Graham" <graham@fify-fifty-forty@removeme@.co.uk> wrote in message
news:#hOoZCoMCHA.388@tkmsftngp09...
Question, how does Ntbackup handle ' open files ' even when you increase
'lock wait time ' especially SQL. Also can it backup individual mailboxes /
restore ?
"Jerry Moore, MCSE/MCP+I/A+" <a_j...@hotmail.com> wrote in message
news:#2GArGoMCHA.1636@tkmsftngp12...
Regarding SBS4.x, I do not disagree. This is not the discussion point of
this topic, however. Or my concern.
>> It just takes knowledge, planning, and good backups.
OK, with SBS2000, I've tried it and failed. Not just me from the NG. To
date, reading between the lines of this topic, no participants seem to have
acquired all of the knowledge, planning skills or, possibly, good backups?
I can accept that, no problem, but I for one will freely admit I haven't. I
need to, though.
>> The only issue' I'm aware of is the long file name issue with some
applications
So what are we missing? Does this LFN issue, which you are aware of,
prevent the server from acting as it should after restore? Can it be
resolved? And more importantly, is it possible to educate our non IT
literate clients (I can't be at my customers sites every day to initiate a
backup procedure that is too complex) to make a restorable backup? Without
blowing their minds with click here, copy this to here etc. Can these known
(to you) issues all be resolved (assuming the knowledge, planning skills and
good backups are all available) after restore? The object is to make a tape
backup that can be restored as a working system. If it requires 24 hours
with regedt32 it's probably not cost effective.
What, exactly, is the correct procedure, Jerry?
Graham
"Jerry Moore, MCSE/MCP+I/A+" <a_j...@hotmail.com> wrote in message
news:#2GArGoMCHA.1636@tkmsftngp12...
In these times after 9/11 we need "no-brainer" bare metal backups. Ones that
work out of the box. We also need a quick recovery. Time is money... I'm
seriously looking into a drive image as an additional backup method.....
Susan
would I fly Jeff to Sydney ? maybe.
would I lodge a PSS incident 'restore has stuffed my system, fix it and all
ramifications of the restore process' ? (I'd like to get away with that one)
What am I suggesting ? That a bare metal restore of a complex server
environment is not a casual user task. I'm more surprised by the relative
success of the operation than the couple of hiccups.
OH well, I'm in the office. Time to give it another go.
"Susan Bradley, CPA aka "Ebitz" SBS Rocks [MVP]" <sbra...@pacbell.net>
wrote in message news:3D3DF112...@pacbell.net...
What we need is a simple procedure. A list of steps required to backup and
restore SBS2000. Jeff said it could be done with registry editing To quote
Jeff ,
"I believe that in 95% of all cases where an SBS 2000 restore has broken
SFNs, a repair of the broken SFNs could likely be accomplished in about 2
minutes *if you knew what to change*. "
Well I don't know what to change and I suspect 99% of this newsgroup don't
know either.
So come on Les produce the list of steps required and we can all give it a
try. Don't keep telling me it's possible if I knew how; We all want to know
how.
Regards
Steve B
"Jerry Moore, MCSE/MCP+I/A+" <a_j...@hotmail.com> wrote in message
news:#2GArGoMCHA.1636@tkmsftngp12...
> Hi Graham,
> I disagree. The only issue' I'm aware of is the long file name issue
with
> some applications. Full recovery of an SBS2k (or even SBS4.x) server is
> recoverable using NT backup. It just takes knowledge, planning, and good
> backups. Anyone claiming that it can't be done is missing something.
>
<snip>
"Steve B" <st...@removemebrecknock.co.uk> wrote in message
news:OVCw5e0MCHA.840@tkmsftngp10...
Mick doesn't think he can do it, he has done it several times in the last 2
weeks.
"Steve B" <st...@removemebrecknock.co.uk> wrote in message
news:OVCw5e0MCHA.840@tkmsftngp10...
Thanks for your support. At least a few people in this group can see why I
started this.
Ghost v7.5 works extremely well if you are using IDE or non raid SCSI disks.
The sad thing is, the better your disk system the least chance you have. I
have no idea how you can do image backups on a hardware raid system.
Steve B
"Susan Bradley, CPA aka "Ebitz" SBS Rocks [MVP]" <sbra...@pacbell.net>
wrote in message news:3D3DF112...@pacbell.net...
If you have succeeded then publish your procedure. Then we can all have a
try. If an SBS2000 restore is possible then it's also possible to produce a
list of steps detailing what needs to be done. I tried to itemise the steps
required from your posts but you backtracked on everything on my list. You,
and everyone else who claims it can be done have failed to produce such a
list.
So far I'm still convinced a full restore off SBS2000 using Ntbackup.exe to
a fully functional system cannot be achieved. It's about time someone in
this group put their money where the mouth is and gave us the procedure we
can all follow.
Steve B
"Mick Malloy" <n...@public.groups> wrote in message
news:e6SYmM2MCHA.1976@tkmsftngp11...
Run the usual tape backups. If a calamity occurs (service pack accident perhaps)
you always have a working system that can be recovered quickly. The data may be
a month out of date but this can be recovered from tape relatively quickly.
Compare this to restoring a system from scratch.
Rob Muir
"Steve B" <st...@removemebrecknock.co.uk> wrote in message
news:e7pyAk8MCHA.2524@tkmsftngp10...
I did another restore today. Used Backup Exec 8.6, with 'open files' and
'Exchange Agent'. The result was actually worse than using the native
NTBackup (which just happens, I believe, to be based on BE). I gotta admit,
we couldn't fix the exchange error. A similar error experienced when doing a
native NTBackup was easily fixed.
Steve,
I just wanna be sure we're on the same wavelength. I ain't interested in
MS bashing or claiming true 'heavy metal' does this better, fact is that the
participants of this group either have or are looking at SBS2K. It is
possible to restore an SBS2K server using nothing more than:
1) NTBackup
2) an OS which can restore the backup.
3) a bit of work/knowledge.
4) and maybe the SBS CD's.
When I restored the LoungeAN and had a broken console I weighted the _known_
console fix against my desire to get to bed. Bed won.
I'll be performing the same test next weekend but I assure you, I'll break
that mirror again justincase it does go pear shaped.
Jeff has alerted us to a problem with SFN's, I appreciate his input but at
this stage I have to suggest that IMHExp this isn't the main problem in a
'bare metal restore' situation. My experience suggests that networking and
exch are the real problems, the SFN issue does not appear to be the cause of
these problems.
I'm sorry, it appears I have misled us, I thought the W2KS image we were
restoring from was a clean retail install, I've been informed it's not, it
is a W2K install from CD1 of the SBS CD set.
for your list:
1) install SBS and patch up.
2) perform full system drive + system state + (if it matters to you)
Exchange backups using NTBackup.
3) in the case of disaster recovery install any OS capable of going into
'directory restore mode' and reading your backup media.
4) restore the boot/system drive (system state and files) in DSR mode.
5) expect errors. Not insurmountable ones but don't sue me if I'm wrong. In
the great majority of tests the result has been positive.
6) reboot (it will inform you you have to) and modify the Exchange stores to
accept replacement via restore.
7) restore Exch.
8) visit every site on the internet to fix the remaining problems. BUT, IME
this isn't _that_ time consuming.
9) chugalug beer, you deserve it. You've just taken a box which not only
died but was originally configured in a way that the providers of the
individual components _strongly_ recommend against. Exchange isn't supposed
to be installed on a PDC, neither is ISA, nor IIS, and I'm not sure (nor
bothered) but guess your SQL Server isn't really supposed to do all these
other things either.
The SBS developers have done a good job getting this bitch to work.I hope
they hear me sucking up and ask the NTBackup guys to fix the SFN problem.
"Steve B" <st...@removemebrecknock.co.uk> wrote in message
news:e7pyAk8MCHA.2524@tkmsftngp10...
despite my experience that I can expect to revive 'the beast' I'm also
looking at alternatives. Worst problem for me is that I need to revert my
system to 'basic' disks in order to reliably image it (unless I have spare
buckaroonies).
I don't consider spare swappable drives an alternative. I don't really
consider a software mirror of my hardware RAID a viable thing, particularly
as I need ~10*HDD's to get MON-THU + Weeklies + Monthlies.
Let's imagine I have a hardware RAID, 3*18GB SCSI's, 36GB usable space (+
the hotspare [drive4] Jeff has almost persuaded me to install). I can mirror
this to IDE's regularly, SO I need 10*40GB IDE drives. If I don't want to
open the box I also need hotswap IDE bays. Tape sounds good in this
scenario.
"Rob Muir" <rpm...@serv.net.au> wrote in message
news:2537484c.02072...@posting.google.com...
> So come on Les produce the list of steps required
Not sure if you're speaking to me or not . . . sorry I can't help you with
the 'bare metal restore' issues. I have successfully done it, but it wasn't
pretty - I had to reinstall quite a bit of stuff after the fact, and did
have phantom nic issues as well. At the time, I put it down to two factors -
my own inexperience, and the fact that I restored from a single processor
non ACPI to a multi processor ACPI hal. So I invited trouble. But it worked.
I know this is not the experience we expect and want - so I think we all
view this thread as perhaps the single most important thread in a while.
By your original post - not considering a disaster recovery test - , I was
under the impression that you wanted to change out your IDE drives with
larger ones. Did you at least succeed there?
--
Les Connor
------------------
When everything else fails, the only thing left to try is . . . . again.
"Steve B" <st...@removemebrecknock.co.uk> wrote in message
news:OVCw5e0MCHA.840@tkmsftngp10...
Recovery procedures for SBS2000 Server
1. Install Windows 2000 Server using SBS disk 1, using same
size C: partition as original.
2. After install completes, and server restarts, change CD
drive to R: and create D: on remaining disk space
3. Install SBS
4. After install completes, move Exchange data to
D:\exchsrvr\mdbdata (including priv, pub, log, sysdir)
5. Install Backup Exec.
6. Change all BE services to use local system account
7. Catalog tape
8. Restart server in DS Restore mode
9. Run BE and restore system state (overwrite all files)
10. Reboot when prompted. Restart will have errors.
11. Restore C:, D: and Information Store, (overwrite all files)
12. Open DOS prompt and change directory to 'c:\program
files\exchsrvr\bin' and issue the command 'eseutil /cc "dirname" /t
(defaults to c:\temp\first storage group)
13. Restart Exchange Server
I've had four attempts at a disaster recovery to my new disks. Each time I
had the same problems with NIC's, which no matter what I tried, I could not
fix.On the last two of the attempts I used exactly the same procedure as
detailed by Mick Malloy as per his message dated Thu, 25 Jul 2002 22:27:18.
and could not resolve the NIC issues. It made no difference if I had working
NICs before attempting the restore of the system state as they were broken
afterwards.
Yes I did swap disks. I gave up trying to restore and used Ghost V7.5 with a
disk to disk copy. It worked perfectly and besides a reboot to "install my
new device" everything seemed to be working fine.
One day later I had a Perflib error 1010 "The Collect Procedure for the
NTFSDRV service in DLL \system32\snprfdll.dll generated an exception or
returned an invalid status" The usual unload and reload of winmgnt counters
and a reboot fixed it. No reoccurrence after three days so far and no extra
'red bangs' in the event log.
Out of interest, On my first attempt at cloning the disks I tried a
partition to partition copy with Ghost and that failed completely; no doubt
due to the SFN issues.
I'm sure other imaging software would probably work just as well, but Ghost
was the one I had closest to hand. (No I don't work for or have any
connection with any software company).
Steve B
"Les Connor" <les.c...@paddockdrilling.ca> wrote in message
news:eeWCAp#MCHA.1744@tkmsftngp10...
The solution I've implied I want to accomplish is not to revise the
registry, rather to revise the SFN assignments for the files and folders.
More specifically, I want to ensure that the entire file and folder tree for
the entire partition is restored with the matching LFN/SFNs as were present
at the time of the backup. This is the only intelligent result to go for.
Following a restore, it's not the registry that is incorrect, it's the
restored files and folders SFN assignments that are wrong. The SFNs have
changed, not the registry. The registry is just one of the possible
locations that can hold a static reference to SFNs. Any application or data
file could also store internal references to SFNs other than in the
registry, and would expect the internally referenced SFNs to still be
correct following the restore. Database applications, embedded documents,
shortcuts, hyperlinks, batch scripts....all of these could make use of
SFNs....and I don't plan to go track down every instance.....every
*possible* instance imaginable, application use, or interpretation of an
orphaned SFN because that would be simply impossible to complete, or know
how to verify if you have completed the process entirely. You will remain in
an unknown status because there's no certainty or verification. The entire
point of the exercise should be to perform a restore that doesn't require
you to wonder what isn't the same as when the system was actually last
running from the condition in which you performed the backup, right?
Therefore, my entire goal is to accomplish the obvious "put it back the way
it was with the same SFNs, doing one of two things:
a) Either ensure that as the files and folders restore, they return to
the original SFN assigned names that were previously held by using a
technique that causes the restore to complete in that condition.
b) Or devise a tool to use that following a restore of the files and
folders, perform an technical process which shifts that assigned SFNs from
their "as restored alphanumeric sequence assigned SFNs" into what results
again in a "SFNs again assigned as they were during the backup creation".
The biggest problem in the entire process is that the SFN restore process is
not being handled automatically, and that you can only know what the SFNs
are assigned to files by looking at them in advance and recording them.
Without knowing what they are before you make your backup, there's no way to
predict what they were following a restore. You have to know them in
advance, and record them in order to ensure you can know when you have
resolved all of the breaks following a restore.
I want to emphasize again something that may be getting lost in this
discussion:
1. I'm extremely confident that it is possible....in advance to know,
predict and....to identify every single file and folder that will be
restored with a different SFN.
2. I'm extremely confident that with a technique that documents the
SFN/LFN association prior to a backup, and then by some process corrects the
SFNs that result from the restore, you would be able to know if you
succeeded 100%, or if there were exceptions that couldn't be returned to the
previous SFN.
3. The exceptions I'm allowing for are not related to a point of
randomness, the exceptions would, could possibly be (I don't know for sure)
possible if a file has an SFN that was assigned to it when it was
created.....and if that file creation predated Windows 3.5 (which is when a
manner of generating SFNs currently used was previously altered). What I'm
saying is it's possible that a very old version SFN might not be possible to
recreate....but the chances of this even happening, and then the chances of
that being a significant file for it's SFN identity.....this is really
getting to remote concern I frankly am not worried about. It's a possibility
a programmer of a utility might have to error trap, but it doesn't strike me
as a concern a System Administrator would consider as an unacceptable
exception to the restore process. A problem with such a file would have to
be resolved in a manner unique to that particular issue. This is just a
trivial point not worth really pursuing in the large context.
4. Some very rare SFNs could possibly occur in theory that would result
in a SFN assignment that might be difficult to determine how to recreate it
intentionally without having more technical information from Microsoft
which, to my knowledge, it's published on how the SFN algorithm works. I
would doubt if 1:10,000 SBS servers might even have an example of this, and
I seriously doubt the file would be registered or a significant risk in SFN
assignment because of the conditions that would be required to even produce
this condition involves large numbers of commonly named files (think 1000s)
where the SFN is also significant, so I'm not even bothering to explain the
point further.
Therefore, the point I'm driving at is that I can imagine a process that
would produce all the certainty you could require that following a restore,
the SFNs would be correct, and the system would be in the original
condition. However, the process to resolve this would involve some uncommon
file handling to accomplish.
The three methods I can imaging that would produce this result are:
+ Restore a partition image (either as the entire backup, or followed by a
file by file restore which would then have the correct SFNs carried forward
by the partition image, and the current file revisions would be carried
forward by the restore.
+ Establish the file and folder structure in the correct sequence to
establish the correct SFNs, then restore on top of it.
+ Restore file by file, then process the files afterward to reassociated the
correct SFN.
The only other method I can imagine would involve the use of Microsoft's API
in such a way that ensures that the SFNs are handled properly in the backup
and restore, and I'm not aware of a technique that allows for this to happen
in Windows 2000 or previous versions of NT.
"Steve B" <st...@removemebrecknock.co.uk> wrote in message
news:OVCw5e0MCHA.840@tkmsftngp10...
Can I just ask about NTbackup, I am concerned with others relying on
NTbackup and not testing their restore. (maybe wishing upon a star or don't
have the experiance.) How does it handle OPEN files, I ran NTbackup up and
the amount of files it skipped due to being open would concern me on a
restore ?
Also Daryl seems to have made a viable solution for restore and yet no-one
has commented on it. It seems spot on to me.
Also one final thing, Anyone tried Veritas Replicator ? I have this on NT4
boxes and works a dream (realtime backup) Will be trying on SBS at weekend
"Jeff Middleton [SBS-MVP]" <je...@cfisolutions.com> wrote in message
news:eiDhGFANCHA.2428@tkmsftngp12...
"Gizmo :-)" <gi...@jcgarden.freeserve.co.uk> wrote in message
news:ujT3mXCNCHA.1888@tkmsftngp10...
Posts like this detract from a previous post. Suggest you read all the posts
again. There has been more than one successful restores done. I DID IT
TODAY, DAMN IT !!!!!!!!!!!
"Graham" <graham@fify-fifty-forty@removeme@.co.uk> wrote in message
news:uZ#LreCNCHA.1596@tkmsftngp09...
p.s please don't forget my earlier post , three or four posts back
"Graham" <graham@fify-fifty-forty@removeme@.co.uk> wrote in message
news:uZ#LreCNCHA.1596@tkmsftngp09...
"Gizmo :-)" <gi...@jcgarden.freeserve.co.uk> wrote in message
news:ehV31kCNCHA.2368@tkmsftngp10...
If you are saying another, third party, software solution works, give us the
details of the product and of the procedure.
Thanks in advance,
Graham
"Gizmo :-)" <gi...@jcgarden.freeserve.co.uk> wrote in message
news:OlnSHoCNCHA.488@tkmsftngp10...
What you are saying here is technical not accurate.
Regarding the SFN problem, it is not SBS2K issues, its an issue that applies
to every version of Windows 2000, Windows XP, and in fact it applies to
Windows NT, Windows ME, Windows 98 (all editions) and Windows 95.
The SFN problem has existed since Microsoft created a Windows version that
supported Long Filenames. The problem originates from the fact that the SFN
is generated dynamically as a file/folder is created in a folder, but the
SFN is never stored within a backup to ensure that when the file is
restored, it has the same identical SFN name, and entire SFN path. The SFN
naming convention is created relative to the files that exist in the folder
at the time the file/folder is being created there. Therefore, the SFN is
relative partly to the LFN name, but also to the "contents condition" of the
folder at the instant the file is being created. The result is that when you
install applications to a computer on day one, the files are created
according to the order in which the applications are installed. However,
when files are restored from backup, the API windows uses, and apparently
offers for *all backup programs that use file by file backup/restore* is
that files are restored in alphanumeric order, not the order used in the
original installation of applications.
You could reproduce this in any version of Windows.
The reason that this SFN problem has been given very little attention over
the years is because either out of habit, backward compatibility, or
cross-platform developement considerations, most all developers have stayed
with 8.3 filenames for all files and folders used in applications....until
recently.
In the time frame of the release of Windows 2000 (Year 2000), this was the
first truly new platform design in 5 years. NT4 and Win9x were designed as a
matched set in many respects from 1995, and prior to that.....there only was
Short Filenames....8.3 convention.
Windows 2000 was designed not only as the upgrade from NT4, but as the point
of convergence where in Windows XP (also based upon similar design thoughts)
would mark the end of Windows 9x product line, and therefore the end of the
last platform intended for transition from the DOS world into the full
32-bit world. It's quite apparent that in this time frame, Microsoft as well
as other developers felt that it was safe to use Long Filenames in the files
and folders of applications, even though there still remain applications
that continue to use 8.3 as well.
For compatibility, MS has kept the very same 8.3 SFN feature present in
Windows 2000 that was in Windows NT....they are the same!
What has changed is that applications are now using Long Filenames for files
and folders when they install......but they are still using Registry entries
that store SFN!!!! This is the problem.
If the applications were storing their LFN names.....there's not problem.
What becomes our problem with SBS 2K is that it installs out of the box with
a set of Long Filename applications from Microsoft that are still making
extensive use of SFN references in the registry. When you perform a restore
from any manner that uses file by file restore, the registry restores in the
exact reference condition for the software settings that were backed up,
including the old SFNs that existed before. However, as the files and
folders are restore, new SFNs are generated based upon the file/folder order
of creating during the file by file restore....and now these SFNs don't
match what is stored in the registry.
This is a Window API problem that has existed for quite some time, the only
reason that we are now becoming aware of it as a problem in SBS 2000 is
because SBS 2000 has a large number of applications with similar program
names that are also LFNs and that are also using SFNs in the registry. Yet,
nothing about this is unique to SBS 2K, it has nothing to do with SBS other
than that any SBS installed in a normal manner creates more than one
registered program with an LFN that will be assigned a different SFN when
restored in Alphanumeric order than it gets when installed in native install
order.
There are further complications in the SFN issues....it's not as simple as
"just restore one folder at a time" because even that doesn't assure the
SFNs will match. It's complicated.
"Graham" <graham@fify-fifty-forty@removeme@.co.uk> wrote in message
news:eNQ89BJNCHA.1632@tkmsftngp13...
>The SFN problem has existed since Microsoft created a Windows version that
>supported Long Filenames. The problem originates from the fact that the SFN
OK Jeff, is the following (over-simplified) scenario the problem?
E.g.
c:\ dir some-directory
A-long-filename-created-1st.txt A-long~1.txt
A-long-filename-created-2nd.txt A-long~2.txt
A-long-filename-created-3rd.txt A-long~3.txt
Now delete "A-long-filename-created-2nd".
Backup to tape.
<<fresh disk, disaster or whatever>>
Restore from scratch.
c:\dir some-directory
A-long-filename-created-1st.txt A-long~1.txt
A-long-filename-created-3rd.txt A-long~2.txt
with the registry entries referring to "A-long~2.txt" being the cause
of the problem!
--
Mike
Some Windows apps remember SFNs to reference LFN objects. There are a lot of
similar LFNs that "hash" to the same SFN before Windows applies some rules
to create unique SFNs. The Windows rules are a function of the LFN and the
environment. The same LFN in a different environment may result in a
different SFN. Windows rules cannot be bypassed to force a particular SFN
even if it would be unique (maybe they can be manipulated). Therefore a
file-by-file restore of LFNs may result in SFNs being different than they
were at the time of backup. Such a difference will break needed links
whether they be in the registry, .INI files, or post-its. Therefore anything
that contains an SFN link to a LFN object cannot be restored with
confidence.
An disk image restore works because it preserves the LFN-SFN correspondence.
Something like Veritas' IDR doesn't have a prayer (well ..... maybe a
lottery ticket).
The general solution using BENT or Microsoft's backup seems to be reinstall
a bunch of stuff, restore over it, and massage until the result is good
enough. If you reinstall and patch just as you initially installed and
patched, you should get the same SFNs that you originally had for
all/most/many LFNs. Therefore you must reinstall and patch everything that
is likely to have LFNs with some SFN links to them. If you
create/change/destroy the LFNs in the same order as they were originally,
the SFNs will be the same. Then the restore of the registry and files with
SFN links will be OK. The massaging comes because something will likely be
different. Hopefully the remaining broken links only cause minor disruptions
until they are found and fixed or recreated.
You can't predict the differences, so it is hard or impossible to lay out
all the steps in advance. The little differences would make something work
for someone and not someone else or even the same person on another attempt.
I don't believe that the file/backup restore programs can provide a general
solution to what is essentially a Windows problem/baggage. I do believe that
they could do a much better job. I can use CMD to force an SFN, so a program
certainly should be able to. If a full backup contained the SFN-LFN
correspondence information _AND_ if no SFNs or SFN links were changed during
the backup, I believe a restore program could preserve the SFN-LFN
correspondence. The backup would be a little slower and the restore might be
substantially slower. You wouldn't have an IDR, but you would have a
HFTRRAMDR (Hellovalot Faster Than Reinstall, Repatch, And Massage Disaster
Recovery).
"Jeff Middleton [SBS-MVP]" <je...@cfisolutions.com> wrote in message
news:urEgftLNCHA.2092@tkmsftngp11...
> Graham,
>
> What you are saying here is technical not accurate.
>
> Regarding the SFN problem, it is not SBS2K issues, its an issue that
applies
> to every version of Windows 2000, Windows XP, and in fact it applies to
> Windows NT, Windows ME, Windows 98 (all editions) and Windows 95.
>
>
etc.
Now I have a little more understanding of the problems, thanks to you,
although a very trusted and able (beyond the ability of most in this NG
IMHO, sorry folks, but I know this is true, I've known him 10 years and he
says..."but, do this this" etc. ... and it works) 'IT literate' friend of
mine has restored an SBS 4.5 to fully working state from tape. Maybe he was
lucky? However, he has also had no success with the 2K version. I am also
not stupid when it comes to this (11 years in the trade, 15 with PC's, 5
years with SBS x) and I can't do it. I will agree that SBS2K can be restored
and tweaked to 90% but not 100%. Broken.
In view of your comments, Jeff, and I have been reading this NG for a long
time and I know your opinion is the most valued and trusted by all, I have
to question the claims by other contributors that the restore process is
easy or indeed possible. I've no experience with Third Party solutions
(although I've asked to be enlightened in this thread, nothing
eard... ),.I've always trusted MS Backup, although from postings in this NG
I doubt that one would fare better with anything else.
The quick/easy/only solution seems to be....
Don't use Ex database, use personal folders. When the 'disaster' occurs,
which it will, re-install and configure SBS, add all the users manually,
restore data (incl PST's) from tape, import the PST's. No red bangs, no
Qxxxxxx, no Technet, hello life. Easier than trying to fix the disaster
that occurs after tape restores. To be totally honest, the trick is
probably not to use any fancy hardware SCSI RAID configuration, but to use
basic IDE HDD's which can (and must) be Ghosted. The ultimate solution?
Maybe this is SBS2K better on low end hardware.
Question... Is there an easy way to get all the users back (e.g. restore
system state withought breaking everything else?). Pass.
To the smug ones who know how to do it, you know who you you are, post the
procedure here. I haven't seen a working scenario so far. Just BS!
Friday PM, late. Gonna play my guitar!
Graham
"Graham" <graham@fify-fifty-forty@removeme@.co.uk> wrote in message
news:eNQ89BJNCHA.1632@tkmsftngp13...
--
Steve Foster [SBS MVP]
---------------------------------------
MVPs do not work for Microsoft. Please reply only to the newsgroups.
With the 2000 generation of products, the default folders are all LFN...
therefore SFNs *do* get generated, and bingo, you just got bitten...
It is possible to do a restore, just not the relatively simple process
it was with SBS4.5.
--
Steve Foster [SBS MVP]
---------------------------------------
MVPs do not work for Microsoft. Please reply only to the newsgroups.
If I had a mission critical system that had to be back online in an hour, at
this point, I wouldn't expect restore from tape to give it to me with a
default installation.
I would not expect that I could restore the system in the known good
condition, only the data and directory services, but the applications would
be assumed to be bad.
A image of the partition is the only consistently reliable backup, but it
requires taking the server offline to image it.
Clearly, you would want to install the server in such a way that imaging
time would be optimized. We can make an intelligent theory that most of the
data files don't matter. The databases like Exchange probably also don't
matter because they are restored as a unit. Therefore, an optimal install
would be to design the install to avoid all SFN collisions by not naming
everything "Microsoft XXXX" because the SFN is going to rely only on order
of installation, not product name for the SFN.
The theory that I believe would solve this in a matter of minutes would be a
tool that would create the files and folders in advance of the restore with
the correct SFNs, then you restore on top of them as an overwrite. This
means that you need an index of the old LFN/SFNs, you need to be able to
reproduce the footprint by creating "stub" files with the correct LFN name,
but created in a sequence that results in the correct SFN name being
assigned. This is an interesting math/logic problem, but it's not even close
to impossible....it's just tedious to get done, but it's not something
anyone is going to accomplish manually with reasonable accuracy or time
required.
"JoeM" <0r88rk...@sneakemail.com> wrote in message
news:eDi09.5312$XG5...@newsread1.prod.itd.earthlink.net...
I've breezed over this issue for about 18 months, just assuming that the
wrong reason was the cause of the problems that were being explained away.
It wasn't until I realized that I had to stop accepting what I considered to
be a conventional wisdom approach, and realized this really takes using all
the skill and experience of how this stuff all works, and then totally
disregarding why you would therefore assume that this sort of mistake
couldn't possibly happen.....it has.
I find no fault with anyone who argues with me about why this can't be true
as long as they continue think about it to arrive at the process that
reveals why it's so clearly a design bug waiting to happen.
I don't recall installing an SBS 4.5 that ever had a problem related to
this, but I'm upgrading an SBS 4.5 this week end and I'm going to look at it
before I whack it.
I'm fairly sure that what was true in SBS 4.5 is that there were only 1-2
folders with the same significant LFN names that resulted in sequential
SFNs, and it was probably the case that they just by coincidence were
scratch installed in LFN alphanumeric order.
With SBS 2000, a couple of things have changed. First, we have as many as
6-7 products installing with sequentially assigned SFN names, plus we now
have the option to install an SBS by upgrading a Windows 2000 server that
didn't come from the strictly linear install of the SBS 2000 Setup program.
Now, add to that....we have many of us who are now trying to keep our old
SBS domain, our old SBS 4.5 install, and upgrading in place......plus some
are having to migrate the installs.....and others are running out of disk
space so we move programs to different partitions......and finally, if
anyone else is like me, you have now reinstalled Exchange 2000 a couple of
times on different servers to correct for problems, so you have a really
good change that you have installed some servers in the original C:\exchsrvr
folder, and other in the C:\Program Files\Microsoft Exchange location, and
yet others in some other location.
There's a lot of complexity converging here.
"Graham" <graham@fify-fifty-forty@removeme@.co.uk> wrote in message
news:#xXc8oONCHA.2028@tkmsftngp10...
Reading thru the posts again I still cant see how Ntbackup will work 100%
cos of the open files issue. Am I missing something...how do you get round
this ? Apart from stopping every service manually or 101 batch files to stop
services before backup....asking for trouble this way.
I see there has been a lot of exchange issues with restore, one aspect which
I had to ensure is ' this database can be overwritten by a restore ' was
ticked in the mailstore properties in exchange. Could this solve your
exchange restore problems ?
Why not download the evaluation www.veritas.com , evaluation has everything
active for your evaluation. (no I don't work for them but spent a year on a
taskforce testing backup progs and Veritas came out top by a long shot for
Microsoft (bottom was Ntbackup, it scored high on file restores but thats
it) Veritas is not easy by a long shot and three years using I am still
learning but I wouldn't trust anything else on my servers.
Finally I will ask again for the Ntbackup users, how do you handle Open
Files ?
"Graham" <graham@fify-fifty-forty@removeme@.co.uk> wrote in message
news:#xXc8oONCHA.2028@tkmsftngp10...
For instance:
Restore to same hardware
Restore to different boot controller
Restore to different hardware, different HAL, different NICs
Restore to only DC in the Domain
Restore to SBS which has another DC that is more authoritative
Restore SBS as authoritative DC to rollback the AD with other DCs
Restore any combination of the above
Restore any combination of the above with only Offline backups of Exchange
Restore any combination of above following dirty shutdown ("crash")
There's any combination of these that makes a recovery inherently unique to
the situation, and exposes the possibility that some little hiccup you don't
recognize looks like your worst nightmare. Yet, most all of these issues are
resolved easily if you understand the process.
The issue with SFNs is that it doesn't matter if you do the process
perfectly, the process has the potential to fail, and you still must
reinstall almost all the applications.
For instance, if you read this KB carefully, and then realize that it's
talking about a Move to a new Machine, but that a bare metal restore even to
the same machine, yet where you are overwriting a reduced complexity partial
install System State with a fully installed SBS 2000 System State, you are
obligated to follow the recommendation to follow that with an inplace
upgrade as a recovery technique!
That means:
+ Prepare installation requirements. Remember, to restore from tape to a
clean install, the system folder name and location must match, and the
installation method (from CD, unattend, distribution method) must match.
+ Install W2K from Scratch
+ Catalog your recovery tape.
+ Recover by restore from tape DSRM Authoritative Restore install for the
OS, applications and data, but not exchange databases which can't be
restored in an Online restore if the Exchange itself isn't already installed
and running.
+ Reboot
+ Correct hardware inconsistencies like NICs
+ Reboot
+ Reinstall W2K as an inplace repair to correct the repair folder
information
+ Reboot
+ Reinstall all the SBS applications to fix the SFNs.
+ Reboot
+ Reinstall all later service packs and patches to return to your production
system level of patching (reboot, reboot, reboot, reboot)
+ Restore your Exchange databases now that you are back again at the same SP
as you originally were in production.
+ Now add all later service packs and patches you hadn't yet found the time
to install to your production system level of patching.
+ Reboot
Okay, now you have everything ready again, but you have nothing close to the
known good condition, you have reinstalled over a known good condition.
Compare that to restoring where you have a Partition Image you can use that
is reasonably close to current.
+ Recover by restore of image to the bare drive
+ Reboot
+ NA [Correct hardware inconsistencies like NICs, they will be right]
+ Recover by restore from tape DSRM Authoritative Restore install for
everything
+ May possibly need to reboot and restore the Exchange databases with Active
Directory running, I don't recall if that's the case
+ Reboot
Which one do you think you can do faster and with more accuracy?
>>>>>>>>.the open file discussion.....non-starter issue for the most part.
There's not a problem related to open files provided that you:
a) Online backup of Exchange
b) Online backup SQL (and don't have open SQL databases that are not
covered, this is the place that Open File for the data does matter)
c) System State Backup.
The files that are open and not backed up other than what this covers are
not significant to recovery, they are recreated dynamically in the next
session.
In a much, much larger network, you might have more concerns for the WINS
database, but not really hear. If you did a lot of complex manual entries
in the WINS, you might chose to script the backup to shutdown WINS, copy the
database file, then start WINS again, but this isn't really important in the
majority of SBS situations.
Open File and Transaction File backups are a totally different issue....so
called snapshot backups that have a point in time restore that is actually
critical to the record by record level, not just that file by file level.
Once you start moving to really intense looks at databases and accounting
systems, you might convince yourself that you need an Open File backup, but
the fact of the matter is that unless the product support Open File restore,
you have wasted your money. An Open File backup of a transaction oriented
database needs to be able to recreate the actual transaction status
including the application's environment in memory! Most accounting systems
and even most databases are designed to keep the files closed, or
recoverable in an open condition, just in case they have to be updated. They
store audit logs of transactions to that the recovery of the process has an
audit trail that the program's own recovery system can correct. You
certainly could argue that it's a good idea to get everyone to log out of
your line of business database system before leaving each day, or to close
the accounting system out, but most programmers realize that's not going to
happen. They therefore write their code to execute as a "file open,
transaction, file close" procedure that concludes in an instant. That's why
most tape backup programs are designed to wait on an open file for a matter
of seconds or minutes.
In most environments, the files that are left open continuously are a
dynamically created file that is based upon caching information that was
already written, or has yet to be committed, therefore the database file is
actually closed in the "last transaction" condition, pending the update of
the "next transaction". Essentially this means that a backup of the system
might miss the posting of a transaction in one file, but not in the other.
When you restore from backup, this means you get an error code from the
program....you call them, they tell you to reindex, and in the process the
program identifies the orphaned transaction and either purges it, or
completes it. This is pretty standard convention.
"Gizmo :-)" <gi...@jcgarden.freeserve.co.uk> wrote in message
news:#aWRgaPNCHA.1352@tkmsftngp11...
because we have. The result using BE was worse than NTBackup. Using NTBackup
I was able to fix the few problems encountered, we're still trying to fix
the box after using BE.
during install adjust all installation paths to satisfy 8.3 convention ?
"Steve Foster [SBS MVP]" <steve....@picamar.co.uk> wrote in message
news:eaFWBLPNCHA.2556@tkmsftngp08...
I am going to spend a few brain cycles on the possibility of writing the app
you suggest. I agree it isn't all that complicated.
However I still have one issue on which I disagree with you.
Using the method I outlined a few messages ago, I have had pretty good
success having minimal lfn/sfn issues. The key location where they occur
today is in the 'C:\Program Files\Microsoft XXX' area. There may be others,
but this is where it hurts in an SBS2000 restore, and what stuffs up the
consoles etc
.
Doing a full install of SBS2000 before restoring gets around this bit of the
issue, because those directories get created in the same order as they were
the first time the install was run. The SFN algorithm is predictable.
But the other issue that seems to be just as major, whicht I dont think has
anything to do with lfn/sfn is problems with NICs and phantom NICs etc. That
is a more major issue to me, which we havent even touched on here.
Regards
Daryl
"Jeff Middleton [SBS-MVP]" <je...@cfisolutions.com> wrote in message
news:ug4DJYPNCHA.2224@tkmsftngp09...
The mirror suggestion is not intended to replace tape backup. It is meant to
make a software disaster recovery faster and more predictable. I don't mean to
mirror a hardware RAID setup, but the system/boot partition is placed on a
software RAID1 as a pair of disks separate to your hardware RAID.
The copies you create are only of the system/boot partion, not the
rest of your data (rely on tapes for this). You do not need Ghost etc to do this
- just remove Disk1 of the RAID1 setup and store it in a secure location
and then use Disk0 to recreate a fresh RAID1 using Disk Manager. Perform this
procedure once a month.
If your SBS install carks it - pull the disk out of the safe and at least you
have an operating system to help restore the rest of your data. This technique
is admittedly easier to apply to a file server rather than systems with Exchange
or SQL databases - but with some modifications the principle still should apply.
Mick, with your setup my suggetion is probably not much help. You have every
thing on a hardware RAID5. I agree that mirroring this would involve too many
disks.
I don't like to have my system/boot partion on Hardware RAID because I think it
is more trouble to recover from a disaster. Also, what happens to you if there
is a fault with your RAID card, or worse, if issues arise with your RAID card
(DELL PERC, Intel RAID cards have had problems)? I prefer to put data on a
hardware RAID and my system/boot drive on software RAID1. If disaster stikes a
combination of the stored system/boot drive and tapes are used to recover.
I think the most reliable way of dealing with this aspect is to either:
1) have the MSLoopback adapter installed from day1.
2) after restore, install the MSLoopback adapter, remove all nics (if
possible, where not possible 'update driver' has fixed it in most cases I
have seen)
There may also be an advantage to use nics which are both:
1) from different manufacturers.
2) natively recognised by SBS2K (or maybe not, I'm still trying to figure
this one.)
"Rob Muir" <rpm...@serv.net.au> wrote in message
news:2537484c.02072...@posting.google.com...
Actually, if MS had not stuck "Microsoft" in front of every product name
when choosing folder names, that would probably have been enough, or if
they'd created a C:\PF\Microsoft\ folder and put everything in there.
--
Steve Foster [SBS MVP]
---------------------------------------
MVPs do not work for Microsoft. Please reply only to the newsgroups.
That, to me, sounds like the easiest fix to implement.
Meanwhile, we must deal with the problem to the best of our ability. I'm
about to embark on an experiment,,, do a standard install and then reinstall
all apps to SFN compatible paths - see if it's possible to take a
'vulnerable' system and make it SFN/LFN compatible.
VMWare, here I come.
"Steve Foster [SBS MVP]" <steve....@picamar.co.uk> wrote in message
news:eO48cXUNCHA.1756@tkmsftngp12...