Moving SERVER System Partition

[John_Aldrich]

Hi, we have a Windows 2003 Server for Small Business which, of course, has Exchange and SQL Server built-in. We are running out of space on the C: partition and need to migrate it to a new drive.

Nigel Bree on the Ghost forum suggested Backup Exec System Restore might do as good / a better job than Ghost would, so I looked at the product. I noticed there is a version for Small Business Server 2003, which is significantly less expensive than the "full" version of BESR.

We are also considering the purchase of an Exabyte VXA-320 tape drive, as we currently only do backups to another drive on the server using Microsoft Backup.

My questions are:
1) Will Backup Exec System Restore for Small Business Server help us migrate to a new hard drive and expand the primary/system partition?

2) Will this version also work with the Exabyte VXA-320 tape drive? I'd read some information on Tom's Hardware (I think it was) when researching this drive that Backup Exec didn't work well with this drive.

We want something that will allow message-level restores of our Exchange database and SQL database as well as disaster-recovery of the server from bare-metal, if it is ever necessary (hopefully not!) If Backup Exec System Restore won't work with this tape drive (Exabyte said to ask you) we will probably have to purchase upgrades/updates to the Tapeware software that comes with the tape drive, and go with Ghost for the partition move.

[techno_nerd]

John,

The BESR SBE will allow you to migrate to a new larger hard drive. What you would do is:

1> Create the Recovery Point of the source drive.
2> Purchase the new drive, and place the new drive in the machine. Set up the partitions in the manner you want (For instance 200 gig drive, 80 gig C and 120 gig D).
3> Restore the C drive and tell it to use the free space.
4> Restore the D drive in the same manner.

Also, BESR is not compatible with Tape drives, so it will not work with your Exabyte VXA-320 tape drive.

Technonerd

[David_Sanz]

John

To protect the recovery points on tapes, you should use Backup Exec as well as Backup Exec System Recovery. With Backup Exec for SBS you will have Exchange and SQL agents, which will let you restore Exchange individual items, for example.

Both solutions together give you what you demand.

Regards

[Doug_Mortensen]

Can anyone confirm that this works? I also am in this same situation with a customer's server & am wondering if this solution can get them out of the situation.

Thanks in advance for your help.

-
Doug Mortensen
Impala Networks
www.impalanetworks.com
CCNA, MCP, A+, Linux+

[Bill_Felt]

Yes, BESR can migrate a server from one hard drive to another.  When migrating to a new larger hard drive, please keep the following ideas in mind:

- BESR supports storing to, and restoring from, disk-based storage such as USB drives, Fireware drives, network locations, SAN/NAS, CD/DVD, etc. (tapes are not supported).  If you plan to use a different storage medium, the backups will have to be written to a supported storage device first and then moved to the unsupported device by a third party application.  When restoring the backups the same is true.  The backups will need to be moved from the unsupported device to a supported device before the recovery can occur.  I would recommend considering use of a supported storage device to simplify the process.

- After installing the new drive to the server and booting the server to the recovery environment, it is recommended you select the "restore MBR", "restore original disk signature", and "set drive active for booting" options.  You do NOT need to select the "restore anyware" option if you are simply migrating to a new hard drive.  The restore anyware option should be used when restoring to a different hardware configuration.  If only moving to a new hard drive (i.e. the hard drive controller hasn't changed) then this option is not necessary.

- You will be given the option to choose a new size for the volume you are restoring at the options screen as well.  You can adjust the size to be whatever you would like it to be. 

- Note that it is not necessary to create a volume on the new drive before you can use BESR to restore the backup to it.  BESR will create (as a part of the restore operation) the correct volume type (i.e. NTFS) etc on the drive, and will expand it to be the new desired size.

Thanks.

[Guido_Langendor]

Added to Bill, PLEASE if you have never done this before, first try this on a non-productive machine!!! After doing all these steps in a test environment, you will make less mistakes when going into production. I have some examples of customers choosing the wrong options and loosing a lot off time...

Regards

[Doug_Mortensen]

Bill & Gudio,

Thank you VERY much for the information & quick responses. Just so that you know, we are using USB hard drives for this. We actually have performed successful recoveries on 3 customer's systems so far with version 6.5 of BESR.

Now let me reveal the rest of the details of this particular situation.

Our customer's current configuration is using 1 simple dynamic disk, with 3 partitions, as well as 17GB of unpartitioned space after the 3 partitions. Their system partition is too small, and they are unable to continue maintaining this server until they can increase the size of the system partition. I would like to use BESR 7 SBS to create a recovery point of all partitions, then destroy all partitions, and recreate them as we'd like. We plan to increase the size of the system partition (C:) by 15 GB, and then allowing the other two storage partitions to equally fill the remaining disk space. All partitions are NTFS. After repartitioning, I'd like to recover/restore the system using the new partitioning scheme so that there is room for expansion on their system partition. They do NOT need to continue using dynamic disks. Using basic NTFS partitions will be fine.

My concerns lie with the Dynamic disk support in BESR, as well as potentially resizing ALL partitions, and then recovering all partitions, and being able to boot and continue to use the system without and problems resulting from this procedure.

The client is ready to purchase BESR SBS, but first we need to be sure that this is going to work for them.

Can you please provide further information about the effective use of Backup Exec System Recovery 7.0 in our situation?

Again, thank you VERY much in advance for your help!

Sincerely,
-
Doug Mortensen

[Bill_Felt]

Hello Doug,

The simple answer to your question is that BESR 7.0 supports backing up and recovering dynamic disk volumes.  If the target drive is empty, then all backups will be restored as basic volumes.

Thanks.

Edit: The BESR 7.0 SRD allows the volumes to be resized during the restore process.

Message Edited by Bill Felt on 05-10-200702:06 PM

[Guido_Langendor]

Hi Doug,

... and again, create a desktop in the same way (dynamic disks, three partitions, etc, etc. Should not taken more as 2 hrs with some copying of data to make it more "real"), create RP's and start with the SRD. Play/test  first so you can create a list what to do in which order when you go into the production server...

Like Bill said, recovery is always a Basic disk which can be converted to Dynamic.

Regards

[Doug_Mortensen]

Gentlemen,

Thank you very much for your help with this so far. We have purchased BESR 7.0 SBS, and are performing this procedure right now. We are having a problem resizing the partitions. The optoins to "Resize restored drive" is disabled, both with the system partition, and with the 2nd & 3rd data partitions. Can you please tell me what we need to do in order for this feature to work?

We are working on this right now, so the sooner you can get back to me, the better.

Thank you very much,
Doug Mortensen

[Bill_Felt]

Are you restoring the partitions individually, or restoring all partitions as part of the same restore operation?  Do partitions already exist on the new target drive, or is it empty (unallocated space)?

If you restore them one at a time (for example, restore the C:\ volume first), then as long as the target drive is empty and has the space available, I believe this option should exist.

Let us know.

[Doug_Mortensen]

Bill,

I was trying to recover all drives at once, using the recover by date feature. I will try to recover each partition one at a time. As long as I do this, and run 3 seperate recovery operations, then I should still be able to resize each of my 3 partitions, including the 1st, which is the Windows Server 2003 SBS install partition? Also, in doing this, are we still clear that there won't be any problems with this operation, considering that the disk is currently a dynamic disk?

I've been told in some of the previous posts in this thread that this is not a problem, and that the partitions will be restored as simple NTFS disk partitions (no more dynamic disk). This is actually our preferred outcome.

I greatly appreciate you help and quick answers to these questions.

Sincerely,

Doug Mortensen

[Bill_Felt]

Hi Doug,

When you say "the disk is currently a dynamic disk" are you referring to the orginal disk from wich the backups were captured, or are you referring to the new, larger disk to which the backups are being restored?

If a backup of a dynamic disk is restored to an existing dynamic volume, then it will remain a dynamic volume.

I'm presuming that the new, larger, target disk is an empty, basic disk, and hasn't already been promoted to being a dynamic disk.  Presuming this is the case, then yes the volumes will revert to basic volumes when we restore them.

I suggest you start with restoring the C:\ volume and confirm that the option to resize is available.  If it is, then resize it as desired and don't check the "reboot when finished" box.  Once the restore is done, complete the restore operations for any other volumes being moved to the new disk.

Thanks.

[Doug_Mortensen]

Yes, the current drive in the server is setup as a dynamic disk. We are actually not replacing the drive. We just need to reconfigure the partitions. This system shipped from Dell with a 7.5GB system partition (C:), and is configured with two other storage partitions, AND 17GB of unallocated disk space at the end of the drive.

Our intention is to leave the current 37GB disk in place, but to create recovery points of our partitions, then to restore booting from the SRD, and at that time resize our partitions to something that is more useful for the long term life of this server (using the 17GB of unpartitioned space).

I'm preparing to create the recover point now. I had to install BESR to the 2nd partition on the drive, because we ran into disk space problems when installing on our system partition.

I'll keep you updated with the progress.

In the mean time, can you please confirm that our plan should work? I will follow your directions for restoring one drive (partition) at a time (w/o rebooting).

Again, thank you VERY much for your assistance.

Sincerely,

-

Doug Mortensen

[Bill_Felt]

Hi Doug,

Well, I'm afraid if the original partitions exist on the drive you are restoring to, then we will not be able to resize the backups during the restore.  By design, if a backup is being restored to an existing partition, we will simply accept the structure of the existing partitions (this is likely why the resize option is greyed out).

In order for the resize option to become available, there must be free or unallocated space available to work with.

This means that you would need to start with a new, empty drive, or remove everything from the existing drive before performing the restore.

There are ways to do the latter option (remove everything from the current drive) from the SRD if you feel that's the best way to go.  Simply do the following (warning: this removes all data and partition structures from the target drive):

1.  At the main SRD screen, move the mouse to the top left hand portion of the window until it turns into a hand icon instead of an arrow icon.  When it turns into a hand, left-click.

2.  A command window will appear.  At the command prompt, type the command "diskpart".

3.  After a few moments, you will be taken to a diskpart command prompt.  At the command prompt, type "list disk".  This will display a list of local disks in your system.  Identify the number assigned to the disk you want to remove all data from. 

4.  Type the command "select disk <number>" where <number> is replaced by the number of the disk you identified in step 3.  For example: "select disk 0".

5.  Type the command "clean".

6.  Reboot the system back into the SRD, and try to restore your volumes one at a time again.  Because you will be restoring the backups into unallocated space instead of existing partitions, the option to resize should be available, and each volume will be restored as basic instead of dynamic.

Thanks.

[Doug_Mortensen]

Hello gentlemen,

It is now Monday, and I want to report on the experience we had performing this operation twice on Friday. Let me first summarize by saying that it went smoother than we could have hoped for.

We performed this procedure first in a controlled lab scenario server Friday AM, then on a customer's production server Friday PM. Both procedures went well overall, with the customer's procedure working flawlessly.

We did have one error message at the first boot up of the customer's server after the recovery, which I will post in a seperate posting after this initial entry. I do need to make sure that it is not something needing further attention.

Now for the report.

Both systems were configured with Windows Small Business Server 2003. Our system had SP1, theirs had no SP's. Both had 1 internal HD with 3 partitions, and a fair amount of unpartitioned space at the end. Both physical disks were converted to a Dynamic Disk within the OS's "Disk Management" tool, prior to installing BESR. Both systems had Backup Exec System Recovery 7.0 Small Business Server.

The following information applies to both systems:

The main objective was to resize the system partition, and expand it, utilizing the unpartitioned space at the end of the physical drive.

The system partition was the first partition on the disk, then followed two storage partitions, then the free space. Since the operating system itself does not allow for resizing the system partition, the plan was to load BESR, create recovery points to an external LaCie USB HD, then boot from the recovery disk, repartition as desired & finally perform the recovery to the new "appropriately sized" partitions. Afterward boot up the system and resume operations as though nothing just happened.

Let me say that that is exactly what we did. The entire procedure on our lab server took about 1-2 hours (we didn't have much data on our storage partitions, or system partition). The procedure on the customer's production server took about 3 hours, since they had more data. We also had to uninstall BESR from the customer's system partition, and reinstall on one of the storage partitions, because the recovery point was unable to initially complete due to insufficient disk space for storing a snapshot image on the system partition (C: ). After freeing up the disk space on the system partition & reinstalling BESR to the 1st storage partition, the recovery points were easily created on the USB HD.

From there , before rebooting, we popped in the recovery CD & selected the option to "Verify Drivers" in order to ensure that our hard drive controller was fully supported in the recovery environment. It was.

So we proceeded to reboot off of the recovery CD. With our lab server, the PCI Adaptec 1200A RAID controller didn't seem to be supported despite the successful findings of the verify drivers tool. So I hopped on to Adaptec's website & downloaded the XP drivers for the controller. I didn't know whether these drivers would work, since the recovery CD for ver 7.0 is running the Vista kernel. But after popping the drivers onto a USB jump drive & using the "Load Driver" tool in the recovery environment, my internal drive showed up with its 3 partitions. There were no driver issues with the customer's server.

I then attempted to recover the systems to the date of the previous recovery points, but it wouldn't let me resize the partitions that way. After consulting the Symantec employees in this forum, I was able to achieve our needed result by going to the tools section in the recovery environment, and selecting the "View/Edit Partitions" tool. With that tool, I was able to easily delete the partition table from the internal HD with just a few clicks (others who do this, will want to take caution & make sure that they don't accidentally delete the partitions on their USB drive, which contains the recovery points. This would be very easy to do, since all available HDs show up in this list.) I did not follow the command-line procedure as suggested by one of the Symantec Employees in this thread.

This worked easily, and I was then able to restore each partition & resize it by restoring one partition at a time (using the recover by "file" method, as opposed to the default recover by date, which automatically recovers all partitions with one recovery operation). For some reason, BESR requires that you restore the recovery points individually, in order to allow you to resize them in the process. This is not really a problem though. I assume that it took the same amount of time total, as it would have to all three partitions in one batch job. So the recovery procedure was to:

1. Boot from the CD
2. Load storage drive if necessary
3. Delete the existing partition table on the destination drive
4. Choose "Recover My Computer", then use the "Recover by File" optinon
1. Select the recovery point for the drive to be recovered (first C: )
2. Proceed & select the desired recovery options (for C: I had EVERYTHING selected), including the desired size of the partition.
3. Let it complete the recovery.
4. Repeat these 4 steps (4.1-4.4) for the remaining partitions
5. Click exit from BESR to reboot & remove the recovery CD

That was it. Very smooth. The disk was no longer a "Dynamic Disk", but we didn't really want that anyway. And even if we did, we could promote it again very easily.

After doing some thorough testing, all data, services, shares, etc were in place & fully functional*. That's some pretty awesome software!! I don't know any way that we could have accomplished this 6 months ago, before Symantec released BESR 7.0. My praises go to the BESR team for creating an excellent product. I also received probably the best & quickest support from Symantec via these forums that I have experienced in any support forum. This was much preferred to our recent experiences calling Symantec's Phone Tech Support, which has required us to be on hold for hours (bad!). In contrast, this experience was very nice.

* = I did experience a few problems along the way, which I think need mentioning.

1. Access Denied Error message when initially performing the recovery procedure. On both systems, when I first attempted to perform the recovery of C: I received an access denied error message. Upon rebooting from the recovery CD, and trying a 2nd time, the recovery proceeded without any problems. I believe that both of these errors occurred just after I deleted the existing partition table. So I am wondering whether there is a bug in some piece of information regarding the disk configuration not being updated within the recovery environment, which needs to be refreshed/updated after the internal HD's partition table is wiped out. However, this is merely speculation, and I really don't know the cause. However, the fact that it was experienced with two totally different hardware configurations causes me to suspect that it may be a bug. So I will include it here in the hopes that Symantec will review it and consider how to eliminate it, as it would save at least 5-10 minutes in the process, as well as some confusion. The error appears after the recovery begins. The progress bar shows up, but it doesn't seem that there is any progress before the message is displayed (and the recovery is stopped). The error message is displayed only a few seconds after the recovery operation begins. I did not write down the message verbatim from the lab server. But the messages were nearly identical between the two systems (if not absolutely identical). The message from the production server was as follows:
1. Error E7C30010 : Device \\.\PhysicalDrive0 cannot write 63 sectors starting at LBA 63. Error 00000005 : Access is denied.
2. On the production server, upon the first boot following the recovery, once that the Windows Explorer shell began to load (explorer.exe). An error message popped up regarding the DC Trust Token. I was unable to find the file it referenced. FYI, I did select the recommended option in the recovery of C: for the DC Token. After not finding the file referenced, I searched the recovery CD & found some similar files. I am not sure what the missing file referenced is supposed to do (although I may be able to guess). Furthermore, it seems that the server (which is an AD Domain Controller) is operating fine. Still error messages usually appear due to errors, and I need to be sure that this error is not going to cause us problems down the line. The lab server was not promoted to be a DC, so this message did not appear, and probably can't even be a possibility if the system is not a DC. The error message had a title bar labeled: "F:\DCTrustTokenReboot.exe".  FYI, F:\ was our 2nd storage partition. The contents of the error message were as follows:
1. Windows cannot find 'F:\DCTrustTokenReboot.exe'. Make sure you typed the name correctly, and then try again. To search for a file, click the Start button, then click Search.
2. As I said, I'm not sure why we got the error, perhaps it's an executible which reboots the server after successfully performing the DC Trust Token preservation process, but I don't know.
3. Last issue (at least the last that we know about) was that on the lab server, after the recovery procedure the Backup Exec System Recovery service would not start. I found this kind of humorous, since at this point, it was really not a big deal. If needed, we could uninstall & reinstall the software, and keep plugging away. Our main objective had already been accomplished. I didn't attempt to troubleshoot this problem, since I was satisifed that our mission was accomplished, and whatever the cause, this last problem would not be difficult to overcome. This problem did not occur on the customer's server.

Overall, I'm extremely pleased with Backup Exec System Recovery 7.0, as well as Symantec's support in this forum. Now that we have successfully performed this procedure twice, we will definitely propose it as a very cost-effective solution to disk space constraints with a lot of these servers with 4-12GB system partitions which are full.

Thanks again to Symantec for this great product & great experience. You have made Us look good before our clients, and we appreciate that. We have already sold 5-7 copies of BESR 6.5 to some of our clients. Some with maintenance, some without. Rest assured that we will continue to push BESR as the best disaster recovery software available.

By the way, would you mind if I mirrored the contents of this thread on my blog? This is definitely worth blogging about. I will link back to the original thread in this forum.

Thanks again,

-

Doug Mortensen

Impala Networks Inc.

www.impalanetworks.com

[Doug_Mortensen]

As stated in my previous post, I need to make sure that the DCTrustTokenReboot.exe error message is not going to cause any problems for our client. Please advise, as to what we should do with this. An explanation would also be helpful.

Thanks again,

Doug Mortensen

[Bill_Felt]

Glad to hear things went well.

I'll check on the DCTrustTokenReboot.exe error and see what I can find.

Thanks.