Read the Manual.doc
Upcoming SlideShare
Loading in...5
×
 

Read the Manual.doc

on

  • 3,134 views

 

Statistics

Views

Total Views
3,134
Views on SlideShare
3,134
Embed Views
0

Actions

Likes
1
Downloads
9
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Microsoft Word

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

Read the Manual.doc Read the Manual.doc Document Transcript

  • SOS Standby Server Disaster Avoidance for Mission Critical Servers Manual for the Windows Platform SOS Standby Server truly is the ultimate high availability solution, providing services, features and reliability that other disaster recovery solutions do not deliver. Consider the advantages of SOS Standby Server:  Provides Up-To-The-Second Real-Time Data Replication.  One-Click or Automatic Multi-Sever Failover: Data Is Immediately Available.  4-Way Backup: Mirroring, Archiving, Drive Imaging and Offsite Capability.  You Can See The Backed Up Files – So You Know Your Backup Is Good.  Automatic Operation with Email Notifications  Allows Users to Continue Working off Backup Server, while Main Server is Repaired.  Can Redirect Storage to any other PC or External Drive.  Drive Imaging of any Computer on your Network.  Can Also Transmit Data to Offsite Storage via Internet with Rsync Protocol or DFS  Offsite Data Reception Server Software Included – 3rd Party Not Required.  No Per-Seat Licensing – Backs Up All Computers on Your Network!  Configurable Data Archiving – Protects Against Data Corruption & Viruses.  Real-time Data Replication with PC to PC Network Software RAID.
  • Table of Contents SECTION 1 - INTRODUCTION.......................................................................4 HOW DOES SOS DIFFER FROM THE COMPETITION?................................4 Licensing & Price….......................................................................4 Multi-Server Failover….................................................................4 4-Way Backup.................................................................................4 SOS Standby Server Is Unique.......................................................5 HOW DOES IT WORK?............................................................................5 SOFTWARE OVERVIEW..............................................................................6 WHAT HARDWARE IS NEEDED?................................................................6 TO CLONE OR NOT TO CLONE...................................................................7 HOW TO PREPARE THE OS ON THE STANDBY SERVER...............................7 CONFIGURING DISASTER RECOVERY ON VIRTUAL MACHINES......................8 ADVANTAGES OF VMS.............................................................................8 WHAT DATA IS MIRRORED?.....................................................................9 EFFICIENT CONVERSION TO VM.............................................................10 SOS COMPONENTS................................................................................10 SECTION 2 - COMPLEX SERVER FAILOVER TO A VM........................11 CLONING PHYSICAL MACHINE TO A VIRTUAL MACHINE...........................11 1. Install OS on Standby Server...................................................11 2. Install VMware on Standby Server Host..................................11 3.Set Static IP Addresses on Host.................................................12 4. Install the Converter on Main Server......................................12 5. Clone Main Server to VM.........................................................12 6. Start VM on Standby Server.....................................................12 7. Install SOS4WIN on Standby VM............................................17 8. Create Software Router on Backup Server..............................17 9. Configure XP VM as a Router:................................................26 10. Set VM To Auto Start..............................................................28 11. Install FAM on Main Server..................................................29 12. Install SOS NetRAID on Main Server...................................30 13. Configure SOS NetRAID on Main Server.............................30 14. Configure SOS4WIN on Standby Server VM........................35 15. Configure Exchange & SQL Batch Files..............................39 16. Active Directory Synchronization...........................................41 17. Test Failover............................................................................42 SECTION 3 - CLONING VIRTUAL MACHINES.......................................49 EXTERNAL DRIVES.................................................................................49 STEP-BY-STEP INSTRUCTIONS..................................................................50 1. Install VMware & Add Datastore on Backup Server..............50 2. Copy VM Files from Main To Backup.....................................50 4. Go To Section 2.........................................................................50 2
  • SECTION 4 - OPTIONAL METHODS..........................................................51 COPYING VM WHILE ITS RUNNING.......................................................51 Method 1........................................................................................51 Method 2........................................................................................51 SECTION 5 - CLONING PHYSICAL PC TO PHYSICAL PC....................53 ON THE BACKUP SERVER.......................................................................53 ON THE MAIN SERVER…......................................................................57 IF THE CLONED PC WON’T BOOT….....................................................61 STEP 2 – CHANGE THE HOSTNAME & IP ADDRESS.................................61 SECTION 6 - SETUP FOR SIMPLE SERVER FAILOVER........................62 INSTALL SOS STANDBY SERVER.............................................................62 IDENTIFY DATA TO BACKUP...................................................................62 CONFIGURE SOS ON BACKUP SERVER...................................................63 DEALING WITH SQL............................................................................66 SQL ON BACKUP SERVER......................................................................66 EXCHANGE SERVER FAILOVER................................................................66 SOS NETRAID...................................................................................67 INSTALL BACKUP SCHEDULER ON MAIN SERVER.....................................67 INSTALL OPEN FILE MANAGER ON MAIN SERVER...................................68 INSTALL OPEN FILE MANAGER ON BACKUP............................................68 CONFIGURE BACKUP SCHEDULER ON MAIN SERVER................................68 ACTIVATING SOS4WIN ON THE BACKUP SERVER................................70 LAUNCH SOS4WIN REPLICATION SERVER…........................................71 Windows Permissions...................................................................71 THE WORKSTATIONS..............................................................................72 CONFIGURE AUTOLOGON AND AUTOSYNC...............................................73 PUBLISH SHARES....................................................................................74 DHCP SERVER.....................................................................................74 CONFIGURE & TEST FAILOVER...............................................................76 Failover Actions............................................................................77 Assume Machinename..................................................................78 Start DHCP Server........................................................................78 Assume Machine Name & Reboot...............................................78 Clear ARP Cache..........................................................................78 WHEN NOT TO PUBLISH SHARES............................................................78 RESTORING IDENTITY.............................................................................79 SYNCING DATA BACK.............................................................................79 Fail Over Procedure for SOS Standby Server.............................82 Fail Back Procedure for SOS Standby Server.............................83 Fail-Over…(Automatic)...............................................................87 SECTION 7 - MISCELLANEOUS CONFIG OPTIONS..............................88 SOS NETRAID...................................................................................88 SOS NetRAID on Main Server.....................................................88 Configure SOS NetRAID..............................................................88 OFFSITE BACKUP...................................................................................90 Configuring Offsite with SOS4WIN............................................90 Configuring Offsite with SOS Backup Scheduler.......................91 Configuring Your Offsite Receiver..............................................93 Troubleshooting Offsite Rsync Connectivity...............................93 QUICKSYNC FEATURE............................................................................94 FILE REPLICATION VIA DISTRIBUTED FILE SYSTEM.................................95 Procedure for 2003 Server DFS Setup.........................................95 3
  • Procedure for 2000 Server DFS Setup.........................................97 Troubleshooting DFS...................................................................98 SDR – SOS DAILY RESTART................................................................99 AUTO FAILOVER FEATURE....................................................................100 GHOSTBUSTER.....................................................................................100 MISCELLANEOUS INFO..........................................................................101 What About Small Business Server?..........................................101 What about Domains & Active Directory?................................102 Can I Use XP as the Host?.........................................................102 TECHNICAL SUPPORT...............................................................................103 Section 1 Introduction Most Important: We are only a phone call away. You have free hands-on tech support during your trial period. Give us a call and we can help you with setup remotely. We always look forward to hearing from you: 480-430-7780 Before we get started lets answer a few questions you may have… How Does SOS Differ From The Competition? Licensing & Price: SOS has no per-seat licensing. The competition is going to charge you for a license for the backup server, a license for the main server, a license for any other server you want to back up. Not so with SOS Standby Server. We provide a site license. One license allows you to backup an unlimited number of servers or workstations to the backup server. No one else offers this generous licensing scheme. Multi-Server Failover: Multi-Server Failover capability means that if any server fails, you can provide failover for that failed server. No one else offers this functionality. SOS will continue to backup other machines, while at the same time providing failover for any failed server. It can even provide failover services for more than one server at a time. 4-Way Backup: SOS Standby Server is really a suite of backup tools. We believe you can never have too much backup. SOS backs up for different ways: 1. Drive Imaging: The GhostBuster Drive Imaging software allows you to create what is called a drive image file -- one big file that contains everything on your hard drive, even files that were locked or in use. And in the event of any kind of problem with your computer, you can simply restore it to an earlier point in time, before you were having any trouble. You can also mount this file as a virtual drive to retrieve any files. You can even clone one machine directly to another through your network. The GhostBuster Server gives you a central repository for managing, receiving and transmitting all your image files. No per-seat licensing means that you may image all servers and workstations on your network. 4
  • 2. Real-Time Synchronization with Failover: The software constantly monitors your server for changes in files and syncs those changes to the standby server. If your entire server fails, you may switch to failover mode. Users are automatically rerouted to the backup server and continue working uninterrupted. The SOS Server can be configured for Auto-Failover or Manual Failover. 3. Archiving: The system automatically archives data. This is important because often database files can become corrupted by power surges, viruses or hardware malfunctions, making your data completely inaccessible. With archived data, you can easily access data from previous days, before the corruption occurred. With the increase in spyware and viruses, data archiving should be an essential part of any backup implementation. One-click-Restore sends any archived file back to the same PC and directory that it was backed up from. 4. Offsite Backup: The system will automatically transmit any data you specify to an offsite location. This protects your data from loss through fire or theft. The data is transmitted securely over your Internet connection to any PC at a residence or alternate business location. Offsite backup provides protection against fire, theft and natural disasters. Offsite Data Receiver Server & Client software is included in the package. SOS Standby Server Is Unique: There simply is no other Disaster Recovery / Failover System on the market that provides such a comprehensive set of backup features. The combination of mirroring, failover, archiving, offsite and drive imaging capabilities -- all in one package -- provides a comprehensive disaster recovery suite that has unparalleled functionality. Continuous real-time mirroring insures against any data loss in the event of failure. Failover provides for instant data availability which avoids costly downtime and loss of employee productivity. Archiving delivers simple, easy, and fast restoration of lost or damaged files, protecting against data corruption and human error. Offsite backup protects against fire, flood, storm, theft, hacker, and terrorist attacks. Drive imaging gives a backup of the entire hard disk, allowing for quick and easy restoration of servers and workstations from bare-metal. How Does It Work? SOS is software that runs on a dedicated backup machine that is running XP Pro, Vista, Windows 2000 Pro, 2000 Server, 2003 Server or 2008 Server. Using the Rsync algorithm it continually monitors any data set you have designated on your main server (as well as any number of other servers or workstations you desire). It can also replicate with our proprietary sync protocol, BCSOS, or with Microsoft’s DFS replication. Update: We are now using a software network RAID driver to write data to the backup server simultaneous with writing to the main server hard disk, so that all changes are instantly replicated to the backup server. If any data changes on any server or workstation it is then replicated over to the backup standby server. Data is replicated in real time at the byte level. In other words, if one record in a database changes, the entire database is not transmitted, only the change 5
  • within the file that contains the record. Thus bandwidth is inconsequential and many gigabytes of data can easily be kept in sync. If the main server fails (or any server on the network that you are syncing), all the network admin has to do is select Failover from the Tools menu, then select the failed server from the list, and click on the Failover button. The backup server will then add the IP address of the failed server to the network card. It will automatically share the data it has backed up on its hard drive with the exact same share name as it was shared under from the main server. The end result is that all workstations “think” that the main server is online and employees can continue to work uninterrupted while the failed server is repaired. In the mean time, SOS will continue to backup any other machines that it was configured to monitor. Is That All? Hardly - SOS does a lot more, like automatic failover capability, sending data to your own offsite location, creating data archive sets, emailing the log files to you daily, and creating “Ghost” type hard disk images. For the whole rundown, watch the tutorial. You can get it here: www.sosstandbyserver.com/download/tutorial.exe Software Overview: SOS Standby Server is very scaleable to your environment. The simplicity or complexity of the setup depends entirely upon your needs. For example if you have a simple file server that only provides network shares that workstations map to, then you can be installed and configured in mere minutes. You simply install the software on a dedicated backup machine and set it to replicate the network shares. Failover mode will add the IP address of the failed server to the NIC and publish the shares with the same share name. Simple, easy, and it just works. If, on the other hand, you have an Exchange Server, domain controller, SQL server, etc which has a more complex configuration, then you will want to clone that server into a virtual machine with the tools provided. A third option is to clone the machine over the network to another physical machine with the provided Ghostbuster Boot CDs. (You may also clone with another drive imaging product of your choosing.) Although cloning physical machine to physical machine is an option, it has more pitfalls, especially if the hardware is not identical. The preferred method is to clone the server into a virtual machine, as that does not require identical hardware, is faster, and is more reliable. What Hardware is Needed? No special hardware is needed. The standby server does not need to be identical or even similar to the main server. You do not even need RAID on the standby. SATA will do just fine. In fact we recommend SATA because it’s cheaper than SCSI. You are going to need LOTS of hard disk space on the backup machine. In fact, you are going to need TWICE the hard disk space of the amount of data you are going to replicate from all of the machines you will be backing up. 6
  • You also want lots of RAM - as much as you can get. 64-bit capable hardware would be ideal because you can make use of more RAM if you run a 64-bit OS for the host operating system. (Your actual server will run as a virtual machine on top of this host) To Clone or not to Clone: If your file server is a fairly simple configuration, for example if it is not a domain controller, not providing DNS, not running Exchange, then you probably don’t need to clone. Simply install the SOS Software on the backup server and configure. You will be finished in a matter of minutes. If you are running SQL, you can go either way. If you don’t clone and you are running a SQL type of application, you will need to install the SQL application on the standby server in exactly the same way and location as it is on the main server. On the other hand, if your server is more complex and is providing network services, Exchange or other server applications, then your best bet is to clone the server into a virtual machine. How to Prepare the OS on the Standby Server: If you already have an operating system on the backup server, then the very first thing you should do is to create a specific user that will be used to logon to this PC to run the SOS application. It is best not to use administrator. This is because servers are often connected to using Remote Desktop as Administrator. If you were to setup SOS under the Administrator account, then any automatic processes set to launch with the Administrator login will get launched a second time when someone remotes in as Administrator. So for this reason it is recommended that you create a user such as SOSBackup and then give that user admin rights. Make sure that user is both Local Admin and Domain Admin, and always log onto the console as this user when installing and configuring SOS. Create this domain user and logon as that user before proceeding. If you are sure no one will ever remote desktop as Administrator to the backup server, then it doesn’t matter. In such cases it is ok to logon as Domain Administrator to do the configuration. Do be sure you have made the backup server a member of the domain and be sure to log on as a domain administrator. Now let’s assume for a moment that you are starting with a blank machine. You have two options: 1.) You can install an operating system. 2.) You can clone the main server. Normally you would install an OS from scratch on the backup server. You may use 2000 Pro or Server, XP Pro, Vista, 2003 or 2008 Server. Keep in mind that if you use XP Pro or Vista for the OS on the backup server, you are limited to only ten concurrent mapped drive network connections. This would be a problem if you have to go into failover mode and there are more than ten workstations on the network. (This is not a factor if you are going clone the server into a virtual machine on the backup server. In other words, you may run a server as a VM on an XP or Vista OS and the 10 concurrent connections limit will have no effect) 7
  • The second option, cloning the main server, has some advantages. It saves a lot of work, as it will exactly duplicate the OS and all of the programs and data that are on the main server. If the main server is running SQL, Exchange, or is functioning as any other type of application server, setup from scratch can take a long time, whereas cloning the system will only require a few minutes of your attention and the rest is automatic. Another advantage is savings in the cost of the OS. Since you are cloning an existing system for backup purposes you are not paying for another operating system. This is a significant savings. The backup server will not be logged onto by any users unless the main server fails. This means users will not access both operating systems at the same time, which should keep you within the licensing agreement. Now for the disclaimer: That is my opinion. I’m not a lawyer. I cannot give legal advice. Cloning an OS and how you use it is at your discretion and for any real legal advice contact a real attorney. Cloning is mandatory if you want failover for Exchange Server. If your server is complex, for example, it is a domain controller, SQL server or provides other network services, it is recommended that you clone it into a virtual machine. If you have a simple file server with shares and nothing more, cloning is not necessary. If you are going to install an OS from scratch and NOT clone, install the OS and then SKIP TO Section 6 NOW. If you prefer to clone the system (recommended), the following procedure will guide you… There are two methods of cloning that you may use: 1. Clone physical machine to virtual machine (Preferred Method) 2. Clone physical machine to physical machine Configuring Disaster Recovery on Virtual Machines: SOS Standby Server is designed to function with or without the use of virtual machines (VMs). SOS has been tested with VMware Server 2. For those who are not familiar with VMs, a VM is simply another operating system running inside a window on another operating system. For example, this document is being written on an XP machine running as a VM in a window on Vista. You can have multiple VMs of different operating systems running on one machine. A VM can be installed from the ground up with an operating system install CD, or existing physical machines may be cloned and converted into a VM. You can think of a VM as just one big file on your hard disk that when launched runs as an entire machine in a window. Advantages of VMs: There are several advantages to using VMs with SOS Standby Server. Servers typically will have numerous software application packages installed, such as SQL, Exchange, etc. If you don’t use a VM, you must install all this software on the backup server as well. While SOS will keep the data in sync, you still have to install all this software, which is time consuming. However if you use a VM, then you have several advantages: 8
  • A. You don’t have to install (or buy) an OS. B. You don’t have to install any software. When you use a VM, you simply clone the main server into a virtual machine with the software provided with SOS. This can be done while the server is up and in use. (However it is better if this can be done at off-peak hours) Once this step is completed you then run the cloned machine as a VM on the standby server. This effectively gives you an exact duplicate of your main server running on your backup server. It won’t matter that it has the same SID and machine name as the original, because the SOS configuration will keep this VM hidden from the main network. No machines on the LAN will be able to see it so there will be no conflict. Using SOS software you then keep the user data such as file shares, SQL data, or Exchange mail stores in sync using our proprietary open-file replication software that allows you to backup files while they are in use. If there are any major updates to the server, the server can easily be re-cloned on a scheduled basis. What Data is Mirrored? SOS only mirrors the user data you specify, such as file shares, Exchange, SQL, etc. Many people question why the operating system and active directory are not continually kept in sync so that the backup server will always have the latest patches, updates and AD user information. There is a very good reason for NOT doing this. The most common cause of server down time is a corrupted operating system that won’t boot for one reason or another. There are multitudes of causes of OS corruption. Usually what happens is some sort of driver or service causes a conflict, or a patch is installed that causes trouble. Other causes are bad memory, power surges, RAID controller failure, virus or malware, and the list goes on of a plethora of factors that can scramble the OS. Once the OS is corrupted, the server may lock up or just begin running very slow. The next logical step is to reboot the server, which sometimes fixes the problem. Unfortunately what often occurs at this point is that the server refuses to boot-up at all. Now, if you have configured to mirror the Windows directory or Active Directory, you will also have the exact same issues on the standby server – something you definitely don’t want! For this reason we do not recommend syncing any part of the server operating system. You only need the standby server temporarily for failover so it isn’t going to matter if every little patch or change is in place in an emergency. When SOS Standby Server goes into failover mode it will confirm that the main server is actually down, then unhide itself by joining the physical network. It adds the IP address of the failed server to the NIC card, sends an ARP broadcast to inform switches and NICS that the MAC address of the cloned server is now associated with the IP address of the failed server. The SOS Failover Module then publishes shares and starts Exchange and SQL services. The end result is transparent to the end user at the workstation. They keep right on working, allowing the network administrator to diagnose and repair the main server without stress from distraught managers and employees. 9
  • Efficient Conversion to VM: The conversion process makes a few large files as it clones your server into what is called a VMDK file. You might want to give some thought as to where you will copy this to. You will be putting these files on the backup server. You may of course just copy them through the network, but that can be slow. Since you need users off the server when this is done, you will normally want to get this done quickly. In order to get the conversion process finished as quickly as possible it is suggested you configure the converter to copy these files to another had disk on the server. Once they are copied then you can let users back on the system and then copy those files again from the internal hard disk off to the backup server. Another efficient way to get the conversion-clone process done quickly is to use an eSata external drive. Most USB external drives come with an eSata connection - which is many times faster than USB. In fact, it is as fast as an internal hard disk. If your servers are not new enough to have an eSata port, you can purchase a couple eSata PCI cards (about 30 bucks a piece) to plug into your main server and backup server to give them this capability. You can then have the converter place the files on the eSata drive, then move the eSata drive to the backup server and copy them from the eSata to the server hard disk. SOS Components: SOS Standby Server has a number of components::  SOSWIN Replication Server: The main application interface. Used to sync data.  SOS NetRAID: A PC-to-PC Software RAID driver used to sync data in real time.  SOS Open File Replication Scheduler: Used to sync locked files with VSS.  SOS Open File Access Module: Allows access to copy locked files.  GhostBuster Drive Image Client & Server: Drive image Utility to clone PCs  VMConverter: Make a cloned copy of a server as a virtual machine.  VMware Server 2.x: Manages running VMs on top of a Windows OS. IMPORTANT NOTE: IF USING 2008 SERVER YOU MUST TURN OFF USER ACCOUNT CONTROL (UAC). To do this go to control panel, users accounts, then choose turn user account control on or off. Set it to off and then reboot. If you do not do this you may encounter problems with permissions in the mirrored data. Not Cloning? Skip To “Section 6 - Setup for Simple Server Failover” Now 10
  • Section 2 Complex Server Failover to Virtual Machines Use the method in this section if your server is complex and not a simple file server. If it is a domain controller, SQL or Exchange server or provides other complex network functions, then use the procedures of this section. Let’s Get Started: The first step is to make a clone of your server and bring it up as a virtual machine on the backup server. Cloning Physical Machine to a Virtual Machine on Standby Server 1. On the Standby Server: Install an operating system. This is what is called the “Host” OS. The “Guest” OS, or VM, will run on top of this “host” OS. You must be familiar with these terms as these instructions will refer to the Host and to the Guest VM. Remember that the Host is the main OS running on the PC. The Guest or VM is the virtual machine running inside the Host. You may use any Windows Server OS for the host. XP and Vista work also. Although XP and Vista are not formally supported for running VMware Server 2.x, many people do use those operating systems without any trouble (author included). If your hardware and OS are 64-bit compatible then you can use all the RAM you can stuff in the machine. Since your host OS is going to use RAM and your guest OS’s will use RAM, you will want all you can get. The added throughput of 64-bit along with the additional RAM gives amazing performance. So even if your existing servers are on 32-bit operating systems, you have an advantage by installing 64-bit on the backup server as the host, as you can then run these 32-bit operating systems as VMs and allocate them plenty of RAM. 2. On the Standby Server Host: Download VMware Server 2.x and install as follows: Use this link to get the software -- http://www.vmware.com/freedownload/login.php?product=server20 This will take you to the VMware site and you will need to fill out a simple registration form to get a free code to run the VMware server. After installation launch VMware Server Home Page – it will be an icon on your desktop. This will launch what is called: VMware Infrastructure Web Access. On the right side, look for Add Datastore. Click it. Here you will enter the path to where you want the VMware data files to live. If you don’t do this it will default to c:Virtual Machines. You may want to change this to a drive that will have plenty of space. Of course if drive C is large enough you don’t need to change it, in which case you can skip the step of adding a datastore. 11
  • 3. On the Standby Server Host - Set Static IP Address: Set a static addresses on the NIC of the host. Make sure you select an address that is reserved or outside the DHCP scope so that you don’t end up with an IP address conflict. 4. On the Main Server: Install the converter software. This software will be used to create a clone of the physical machine to be used as virtual machine, which will be put on the standby server. VMs are hardware independent, so it won’t matter if the standby server is different hardware. Click the link below to download and install the converter on the main server that you wish to clone: Note: The install will ask you if you want client/server or stand alone. Either is fine www.sosstandbyserver.com/download/VMConverter.exe 5. On the Main Server: Run the Converter Standalone Client. a. Select: "Connect to a local server." Click Login. b. Click "Convert Machine." c. Select Source Type: "Powered-on machine." d. Select "This Local Machine." e. Click Next f. Select Destination Type: “VMware Workstation or other VMware virtual machine." g. Select VMware Product: VMware Server 2.x h. Name: (whatever you like) i. Choose a location for the virtual machine. This can be a network, local, or external drive. Typically you would send these to the datastore location on the standby server, created in step 2 above. j. Click Next. k. Click Next l. Click Finish 6. On the Standby Server Host: Start the VMware Infrastructure Web Access interface. (Its an ICON on the desktop.) a. On the right side under commands click on “Add Virtual Machine To Inventory.” Note: These instructions are assuming you copied the VM files over the network to the backup server. If you used an external drive, then you move the external drive to the backup server and copy the VM files to the appropriate location before proceeding. b. Drill down in Inventory and Contents until you see the file with the vmx extension. Highlight that and then the OK button will not be grayed out. Click OK. 12
  • c. Before you start the VM, you must make sure that it doesn’t come up on the main network. For now, you may simply unplug the network cable to accomplish this. This is vitally important! If you don’t do this, and your main server is up, you can cause IP, machine name, and service conflicts on the physical network. So unplug the cable now. d. Another thing that must be done before you start the VM is to add a second LAN interface to the VM. This is easily done in VMware Infrastructure. Click on the VM in the left-hand pane and then in the right- hand pane click Add Hardware. Then click on Network Adapter. Follow the prompts and take the defauts. Before you start the VM, carefully read the note below: 13
  • Important! – The first time you start a VM that you have copied or cloned, it might ask you if you “Moved” or if you “Copied” the VM. If asked, you want to answer that you “Moved” it. If you don’t answer “Moved” the VM will not work properly in failover mode. This is because “copy” will cause VMware to give this VM different network identification information, such as SID, MAC, etc. We want it to be identical to the main server in every way, so for this reason we select “Moved.” If you are sure the network cable is unplugged, then go ahead and start the VM. Click the green arrow to start it. Starting the VM Then click on the Console Tab and click anywhere in the window to connect to the machine. Add the browser plug-in if advised. You will then see your virtualized machine booting up. Immediately after the first start of the VM you will want to add the VMware Tools to increase performance. You do this by clicking on "Install VMware Tools” on the right hand side of the Summary Tab page. Then follow the installation prompts in the console of the booted Guest VM. If you don’t get any prompts, go to the CDROM drive in the VM and run the setup program there. EXPLANATION: Before proceeding some explanation is in order. We now have an exact clone of the main server created and running as a VM on the standby server. What we need to do now is to configure a way to send data from the main server to the standby server so that it will always have the latest up-to-second copy of changing data. This is a bit of a trick, because the cloned server can’t be brought onto the main network when the main server is up. This is because it has the same SID, MAC, and Machine Name as the main server and may be running other network services such as Active Directory, DNS, DHCP, etc. These things will interfere with the main server. For this reason the standby server is sequestered into a network with a different subnet from the main physical network so that computers on the network can not see the standby server. Only in failover mode will the standby server actually join the main network. 14
  • Note: Although we speak of “two different networks” there are not two physical networks. Everything runs through the same cabling. Different subnets (networks) can coexist on the same cabling without ever seeing each other. This feat is accomplished by creating another VM inside the backup server that will function as a router to transfer data from the main server to the standby server guest VM. We will get to that in a moment. e. On the Guest VM - IP Addressing & NIC Configuration: Now that the virtual machine is up and running, you need to make some changes to the LAN interfaces. Control Panel / Network Connections The interface called “Local Area Connection”: This will be the one that is configured with the same MAC address and IP addressing that is identical to the main server. You don't change any addressing on this NIC. We want to disable this interface. The failover routine will bring this online when it is needed. For now it must be off so that it will not conflict with the main server. Right- click this interface and click on “Disable.” The interface called “Local Area Connection 2”: Now right-click on the other LAN Interface, mostly likely called “Local Area Connection 2.” Click on “Properties.” and double-click Internet Protocol TCP/IP. Select “Use the following address,” and give this NIC a static address. Assuming your network addressing is class C, then make the third octet of the IP different from your main network so as to put the standby server VM on a different subnet, effectively sequestering it away from the main network. Example: Your main network has addresses of 192.168.10.x This virtual NIC must be given an address such as 192.168.20.x. If the main server is: 192.168.10.10 then, to make it easy to remember, give your standby server the address of 192.168.20.10 DNS Address - Check “Use the following DNS server addresses” and give it a static DNS server address. Set it to be itself, which would be its own IP. In the example above the IP is 192.168.20.10, so you would also set the DNS to that same address. Setting this DNS is important because if this OS is running a DNS server, the operating system will become quite unhappy upon reboot. It will hang for what seems like forever on “Preparing Network Connections.” Giving it its own address for DNS will cause it to 15
  • always look at itself for DNS resolution. So if it has a DNS server, be sure to do this. (You can check in services and see if DNS Server is enabled.) Gateway - You are going to use 192.168.20.1 for Local Area Connection 2. When you are finished you can run ipconfig from a command prompt and you should see something like this: Local Area Connection 2 IP Address 192.168.20.10 Subnet Mask 255.255.255.0 Gateway 192.168.20.1 EXPLANATION: The reason for giving the standby server a different subnet address is so that it will be sequestered from your network. You don’t want your regular network to see the standby server because the standby is an exact duplicate of a server on your network. If they were to ever see each other bad things would happen! You would have IP, SID, Service, and Active Directory conflicts. Not pretty. As long as you are on different subnets the standby server is safely isolated. When the main server is down and you go into failover mode, the SOS software will bring the standby server VM onto the main network. Since the standby server is sequestered with a subnet address, there needs to be a special means of reaching it in order to sync data to it from the main network. As mentioned above, this is accomplished with a VM acting as a router. One of the interfaces of that router will be 20.1. f. Turn-off Services on Standby Server VM: On the standby VM turn off Exchange services, SQL services or any other service for which you will be copying data for. You will not be able to write the Exchange or SQL data into the data store locations if that service is turned on. That is the reason for turning them off. They will come back on automatically in failover mode. Go to start/run and type in services.msc to load up the services applet. Take note of all the Exchange or SQL services that are set to run Automatic and change them all to Manual. The SOS Failover process will control when they start and stop. After you set them to manual, turn them off. Note: Turn off anti virus software on the VM. g. Plug-in the network cable. As soon as you have disabled the LAN interface “Local Area Connection,” as instructed above, it is safe to plug in the network cable. 16
  • 7. Install SOS Standby Server on Standby VM: The standby VMs don't have Internet access, so you must download the software on the Host. So from the host use this link: www.sosstandbyserver.com/download/winsetup.exe Copy the downloaded file to the Guest Standby VM and run it to install the SOS Software. In order to do this you will need to map a drive from the VM to the Host in order to transfer files between the Host and the Guest VM. Note: During the install, when you are asked if you want to install the NetRAID driver, answer “No.” There is no need to install that on the standby. 8. Create Software Router on Backup Server: This is done by installing XP Professional on Host of the backup server as a VM. h. On the Host, open VMware Infrastructure. Click on Virtual Machine and select Create Virtual Machine 17
  • i. Change the name to be whatever you want. If you have multiple datastore locations, click on Datastore and select the datastore location you want to use. Click Next j. Select Windows Operating System and Select Microsoft Windows XP Professional (32-bit) from the drop down menu and click Next. 18
  • k. Select 256 MB for RAM. This is all you need since its only going to do routing. Click Next. l. Click Next to accept the default to create a new virtual disk. 19
  • m. Select at least 2 GB for the capacity of the disk. Again, since this is only going to be a router, no need to give it more disk space. Click Next. n. Click Next to accept the default to add a network adapter. 20
  • o. Click Next to accept the default "bridged." p. Click Next to accept the default choice of using the actual physical CDROM drive as the CDROM drive for this VM. 21
  • q. Click Next to accept the D drive as the default letter for CDROM. r. Click on "Don't Add a Floppy Drive." 22
  • s. Click Next to take the default of adding a USB controller. (or not - it doesn't really matter.) t. Click More Hardware. 23
  • u. Click on "Network Adapter." v. Click Next to accept default setting of "Bridged." 24
  • w. Click Finish. x. Place a Windows XP Pro install CD in the CDROM drive and then in the Console Tab, click the big white arrow to power on the machine. 25
  • y. When this screen appears, click anywhere in the black area to attach to the installation and view the install process. Install XP as you normally would. 9. Configure XP VM as a Router: A. In VMware infrastructure, configure XP VM with two NICs and then start the VM. B. Run Regedit and configure as follows: • HKEY_LOCAL_MACHINESYSTEM/CurrentControlSet/Services/Tcpip/ Parameters • Right click IPEnableRouter registry object, and click Modify. • The IPEnableRouter window will appear. Type 1 as Value data and click OK C. Configure Local Area Connections as follows: Note: Address of this first Local Area Connection is based upon whatever the address of your network is. This example assumes you are using 192.168.10.0. So Change this accordingly. Local Area Connection IP Address: 192.168.10.254 -- (See Note Above) Subnet: 255.255.255.0 Gateway: 192.168.10.1 This assumes your regular network gateway is 10.1. Change accordingly 26
  • Local Area Connection 2 IP Address: 192.168.20.1 Subnet: 255.255.255.0 Gateway: None D. Reboot, and then open a command prompt and type: IPCONFIG /ALL and check and make sure you see: IP Routing Enabled…………Yes E. Open a command prompt and enter these commands: ROUTE -p ADD 192.168.20.0 MASK 255.255.255.0 192.168.10.254 ROUTE –p ADD 192.168.10.0 MASK 255.255.255.0 192.168.20.1 Note: The first command tells it that anything coming in through the 10.254 that is designated for the 20.0 network is to be sent to Local Area Connection 2. The second command gives it a return route, so that anything sent from the 20.0 network can reach the 10.0 network. The –p makes the route permanent so that it will be retained upon reboot. On the Main Server… F. Change the Gateway address on the main server to be 192.168.10.254 • IP Address: 192.168.10.10 • Subnet: 255.255.255.0 • Gateway: 192.168.10.254 Note: All traffic for the Internet will now route to 10.254 and then be routed to 10.1 and go out to the Internet. All traffic for the 20.0 network will go to 10.254 and then to the 20.1 interface. G. Map any necessary drives from the main server to the standby server using IP address: 192.168.20.10ShareName Note: This assumes your sequestered standby VM is 20.10 and the ShareName is actually ShareName. Adjust accordingly for actual IP and ShareName.) H. Troubleshooting: If everything is working correctly you should be able to ping from the Main Server to the Standby Server VM. You should also be able to ping the Internet. Test pinging from the source PC (Main Server) to the destination PC (Standby Server VM) on the other subnet. If you can’t ping then do this: On the source PC (Main Server) do: 27
  • Route delete 192.168.20.0 Then ping again. If that has not fixed it, then on the XP Router VM do this: Route delete 192.168.20.0 Route delete 192.168.0.0 Then test again. If it still doesn’t work add the routes in again on the XP Router VM as in Step E and re-test. 10. On the Host - Set VMs to Start Automatically When Host is Rebooted: You will want to set all VMs to start automatically when the host (the physical machine) is restarted. The router VM should start first. Here is how you configure this: In VMware Infrastructure click on the host machine at the top of the window. In the example below QUAD-64 is the name of the physical host machine. It is highlighted because it has been clicked on. On the right hand side you will see “Edit Virtual Machine Startup/Shutdown.” Click on that. (see picture below) 28
  • The window shown below will pop up. Check “Allow virtual machines to start and stop automatically with the system.” Highlight your virtual machine and click “Move Up” until it is in the “Any Order” section and startup says “Enabled.” 11. Install Open File Access Module on Main Server: Download from here: www.sosstandbyserver.com/download/SOSFAMTrial.exe 29
  • Again, it doesn’t say so after the install, but it does require a reboot after installing. You must restart after step 12, so wait until that is done before restarting. 12. Install Replication Scheduler and SOS NetRAID on Main Server: Download from here. You would select the first link normally. If anyone is using vista or XP as a server then you would select the second or third link. When are asked during the install if you want to install SOS NetRAID drive answer yes. Server OS: www.sosstandbyserver.com/download/SetupScheduler4Servers.exe Vista OS: www.sosstandbyserver.com/download/SetupSchedulerVista50.exe XP OS: www.sosstandbyserver.com/download/SetupSCheduler50.exe Note: Restart main server now after installing. Note: The NetRAID driver runs as a service. Some servers may be running other drivers which may not be written to approved standards. These may conflict with the NetRAID driver. If you have any issues booting the server after installing the NetRAID driver, reboot, hit F8 and select “Last Known Good Configuration.” That will boot the server up without the NetRAID driver. Then call us for technical assistance at: 480-430-7780 13. On the Main Server - Configure SOS NetRAID: First, if you have not yet done so, map a drive from the main server to the Standby Server VM. You will map to the administrative share to the root of each drive, for example C$, E$, etc. You must map this with IP address, for example: 192.168.10.20C$ 30
  • Launch the SOS Data Replicator – Start / All Programs / SOS Open File Replication Scheduler / SOS Backup Scheduler. Then using the Network RAID function of the backup scheduler, you can configure RAID synchronization from the main server to the Standby VM. Select the data source in the Source directory Window, and then select the destination in the Destination Directory Windows. The destination will be the drive that you just mapped. The Network RAID will automatically create subdirectories on that mapped drive as the data copies. After you have selected Source and Destination, then click on the Network RAID button. All the data will copy initially. After that, data writes will occur simultaneous with writes to the main server hard disk. Note: For the initial copy, turn off any antivirus software. If possible, leave active protection for antivirus off on the server and only set the antivirus to periodically scan for viruses. Active protection of AV can be very intrusive and sometimes interferes with replication. Whether or not your AV will conflict depends on what you are using. This is a personal call and you may not have a choice, depending on your companies regulations. Just keep this in mind that if you have any issues later, suspect first the AV software. Note: You can check the status of replication by going to Start / All Programs / SOS Standby Server / SOS NetRAID MirrorFolder. 31
  • Network RAID Repeat this process for all data on the main server that you wish to replicate. After you have completed you can launch the SOS NetRaid Mirror Folder application to view what you have setup. Do this: Start / All Programs / SOS Standby Server / SOS NetRAID MirrorFolder. Be certain all your shares are in the list and that they are set to mode RAID-1. You may also configure your NetRAID mirroring from this application as well. 32
  • Explanation: Similar to a software-only RAID-1 system, the network raid function duplicates individual file I/O requests in memory and sends them to both source and mirror devices at the same time. The uniqueness of this is that it actually is RAID to another PC. For example, if you have a large database file in your source folder and modify only one record in that file using the application interface of that database, the Network RAID driver will modify only that same record in the mirror database file simultaneously, and will NOT copy the entire source database file to its mirror. The advantages of network RAID are that there is no lag time in data synchronization - it happens in real-time and will keep data in sync even if the files are in use and locked. This is because it doesn’t have to actually read the file, but catches data writes in memory before they are written to disk and sends them to both the local disk and the network location at the same time. This is an excellent option to use for SQL or Exchange data. Important: Although the SOS NetRAID driver can move data that is written to locked files (because it catches the data before it is written to the file), it cannot actually read and send a locked file. What this means is that you must first get the locked data moved over before the benefits of NetRAID can be used on locked files. This can be done in two ways. You can turn off the SQL or Exchange or whatever service has the files locked. (Alternatively, you could boot up in safe mode with networking, temporarily.) You can then copy the data over to Standby Server VM. It is best to make this data copy with the associated service off, however if that is a problem, another method can be used to copy the data while the service is running. This is done by using the SOS Open File Replication Scheduler to copy the data. The SOS Scheduler works in conjunction with the SOS Open File Module and will send locked SQL or Exchange data even while it is in use. You do this AFTER you have configured the NetRAID replication, then you use the SOS Scheduler and select source and destination. Then type in a name (8 characters or less), and click on Backup Now. (You do not need to check “Get Open Files.” If the SOS Open File Module is installed you do not need to check that.) Note – Exchange Data: After the replication completes you can click on SOS Compare and then click the unequal button and view the split windows to confirm that the data is in sync. After the initial data copy is complete, the NetRAID driver will keep the data in sync. See figures below… Note: The NetRAID driver runs as a service. Some servers may be running other drivers which may not be written to approved standards. These may conflict with the NetRAID driver. If you have any issues booting the server after installing the NetRAID driver, reboot, hit F8 and select “Last Known Good Configuration.” That will boot the server up without the NetRAID driver. Then call us for technical assistance. 33
  • Note: Be aware that when doing data comparisons, the NetRAID Mirror driver will hold intercepted data in RAM and may not write it until NetRAID is stopped or the connection is broken. . 34
  • 14. Configure SOS4WIN Replication on Standby Server VM: Start / All Programs / SOS Standby Server / SOS4WIN Replication Server. You can type DEMO when asked for a code and it will run for two weeks. After the program loads, click on Options / Settings and enter the default authentication information. Then click OK to close. This step is essential in order to create the initial program INI files look at Help / Tutorial for a quick visual overview of how to setup to replicate shares. If you have not yet done that, now is a good time. You will configure this application to look at the main server for source and the Standby Server VM as the destination. You will normally not turn on replication. The replication features of the SOS4WIN program are used in simple server configurations. This is a complex server setup and the NetRAID does most of the synchronization for you. You are mostly doing this so that you can right-click on any share and select “Compare Local-Remote Data” and insure that all data is in sync between the main and standby servers. You do have the ability to sync the data with this. It will work in conjunction with the SOS Open File Module so it will backup locked files. If you do move data with it, we suggest you use the QuickSync feature from the Tools menu. QuickSync keeps the ACL permissions intact, whereas the standard sync uses the Rsync protocol which tends to occasionally “mess” with the permissions. Also the QuickSync will copy the data faster. Above is an example of a replication setup for the mail-store data from an Exchange Server on the physical network. Note here that the source is not 35
  • mapped with MachineNameShareName, but rather is mapped with IP address. You will note that it is using 192.168.10.10MDBDATA. It must be done with IP because the VM has the exact same name as the real server. If you use the machine-name, you may map to the standby server VM instead of the main server. You will note when setting up these replication shares that the default location to store data is in C:SOSMirror and C:SOSArchive. If you right-click on a configured replication share in SOS4WIN and select properties you will see the default location for storing data. This is where you will change it so that the storage path sends it to the mapped drive and directory location where the data should live on the standby VM. You can just type in the path, or you can click the button to browse to it. If you use the browse button you will find that the program will automatically create a unique path by adding the machine name and share name to the path. If that happens, just delete out what the program put in so that it will go the exact same place on the standby that it was in on the main server. Here is an example of how you would configure Exchange Server replication. You will right-click on the share and select Properties and change the Mirror Path. You want the destination to be the correct location for the Exchange server. You will set the proper location, in this case it would be:C:Program FilesExchsrvrMDBDATA Change Mirror Path on Exchange or SQL Data 36
  • After you click on OK, go back in and make sure the program did not automatically enter the server name and share name at the end of the path. This is the default behavior to preserve unique storage path names, but in this case you don’t want that. If you see that, take it out so it is as in the picture above. You will want to replicate to C:Program FilesExchsrvrMBDATA. The main reason for configuring this is so that you can get a quick visual check of the data to make sure it is in sync. You do this by right-clicking on a share and selecting Compare Local Remote Data. Below is a screenshot of SOS4WIN configured for three servers: . Below shows the right-click to bring up the data comparison… 37
  • Below you see the data comparison window which compares local and remote data. In other words, the actual data on the main server is on the right and the mirrored data on the standby server VM is on the left. Below you see the same window after clicking the unequal button. You can see in this example that not all the data has been copied. Ideally both sides have 38
  • nothing listed after clicking the unequal button. In this scenario you would click the “Sync-to-Left” button to correct the issue. This will copy the data from the main Exchange server and write it into the data location of the standby Exchange server. You will be able to copy this data from the main server while the Exchange server is up and running, by virtue of the SOS Open File Access Module. You will be able to write it to the backup server because you will have turned off the Exchange Services on the backup machine. Additional screenshots and instructions concerning the use and abilities of this powerful application are covered further in Section 5. 15. Configuring Exchange and SQL Failover and Restore Batch Files: As already mentioned, application server services such as Exchange or SQL must be off on the backup server so that data can be replicated into their location and the existing data overwritten. You cannot overwrite this data if its corresponding service is turned on. Consequently you turn these services off, set them to manual and let SOS control when they are on or off. The check boxes on the Failover Control Panel applet determine if these batch files are run. For example, if Start Exchange Srvr and Start SQL Srvr are checked, then Exchangestart.bat and SQLStart.bat will be run when you click “Failover” and ExchangeStop.bat and SQLStop.bat will be run when you click “Restore Identity.” There are four batch files that you may need to edit in order to properly configure failover for Exchange or SQL. These files are: Exchangestart.bat 39
  • Exchangestop.bat SQLStart.bat SQLStop.bat Below is an example of the Exchangestart.bat. You will need to run services.msc from the run window and look at your Exchange or SQL services that are set to start automatically. You can load these batch files into notepad and edit them accordingly. You will look at the services that are set to run automatically for your Exchange or SQL and note the name in the list and then put that name in the batch file. Put it in quotes right after the net start command in Exchangestart.bat or SQLStart.bat, or after the net stop command if you are editing the Exchangestop or SQLStop file. @echo off cls color 17 echo. echo. echo Resetting Permissions on Exchange Data... echo. cd "program filesexchsrvrMDBDATA" c:rsyncchmod -R 777 * echo. Echo Starting Exchange Services, Please Wait... echo. echo. net start "Microsoft Exchange Information Store" net start "Microsoft Exchange Management" net start "Microsoft Exchange MTA Stacks" net start "Microsoft Exchange Routing Engine" net start "Microsoft Exchange System Attendant" echo. echo. echo Exchange Services Started. echo. echo. echo. Pause The SQL or Exchange batch files can actually be used for any other service. For example, maybe you are not running SQL, but you are running some other database type service that needs to be off, but come on in failover. You can edit the SQLStart and SQLStop files and check SQL in the failover module and those services will be controlled, even if they are not actually SQL services. After running services.msc, make note of all the Exchange or SQL services that are set to run Automatic (see figure below). Change them all to manual because on the backup server, SOS Failover will control when they start and stop. After you set them to manual, turn them off. 40
  • 16. Active Directory Synchronization: If the main server is NOT a domain controller you can skip this section and proceed to section 17. If it is a domain controller then you will need to configure replication of the Active Directory from the main to the standby server. It is not absolutely necessary to do this, but if you don’t, be aware that any password changes or new users or new computers added to the main server will not be added to the standby server. You would have to make these changes manually to the standby server as you make them to the main server. If you choose to go that route you will certainly want to make some changes in group policy on the main server so that forced password changes do not occur monthly, which is the default for 2003 server. To avoid all that hassle you will probably want to synchronize the Active Directory between servers. However you do not want this replication to happen in real time. Why? Because most server boot failures are due to operating system corruption. If the Active Directory on the main server becomes corrupted, and if you are always replicating Active Directory to the standby server, then you will have a corrupted AD on the standby server at the same moment it corrupts on the main server. This could possibly make the standby server unusable. This completely defeats the purpose of having a standby server. Therefore we have implemented a module for SOS Standby Server called SOS Active Directory Replicator (ADR). The ADR module will replicate the Active Directory from the main server to the standby server on a weekly basis. This schedule can be modified to your preference. The backup and restore can also be run manually at will. This will allow for changes in users, computers and passwords in active directory to be reasonably up-to-date on the standby server yet still be protected from any OS corruption that may occur on the main server. 41
  • In the event of suspected problems on the main server the weekly replication of Active Directory can be turned off until the situation is resolved. The nuts and bolts of how this works is as follows: The ADR module sets a task in Scheduled Tasks that will back up Active Directory on the main server every night at 2:00 AM. The AD backup files are placed in c:StagingFolder. The NetRAID MirrorFolder application will be configured to replicate this to c:StagingFolder on the standby server every day at 2:30 AM. Every Friday at 3:00 AM the standby server will reboot to Active Directory Restore Safe Mode, restore AD using the data in c:StagingFolder and then reboot to normal mode. The SOS ADR module may be downloaded from here: www.sosstandbyserver.com/download/SOSADReplicator.exe You will run this installer on both the main server and the standby server. The installation will ask you which you are installing on and install the proper files for the main and standby servers. After you have completed the setup on both servers, be sure to go back to the main server and configure MirrorFolder to replicate c:StagingFolder to c:StagingFolder on the standby server. It is recommended that you test it by manually initiating an Active Directory backup. This will not impact users and is completely safe to run at any time. You can right-click the job in Scheduled Tasks to run it or you can select “Force AD Backup Now” from the SOS Standby Server Program group. Tell MirrorFolder to replicate this immediately. Then on the standby server force the restoration of AD by either running it from Scheduled Tasks or from the SOS Standby Server menu by selecting Force AD Restore Now.” The ADR module can also be used as a stand-alone application without an SOS Standby Server. ADR will backup Active Directory and allow you to restore it to the same machine, or to a different machine. For example, if you have to reinstall the OS, or if you have replaced the server with one that has a new OS, you can restore your backup of Active Directory to this OS, provided it is the same OS version. This effectively gives you complete Active Directory protection without having to install a second domain controller. To backup or restore in this manner you simply select SOS Active Directory Replicator from the SOS Standby Server program group. 17. Test Failover: Setup of SOS Standby Server is not complete until you have tested failover. You want to make sure that the standby server will operate as needed in case of emergency. If you have missed a step you will want to catch it before it’s too late. Thus testing failover is considered an essential part of setup. You will want to take the main server down and put the standby server into 42
  • failover mode and then go to workstations and make sure everything is working. It is not uncommon to discover that you overlooked something when doing this test. You will of course have to schedule down time on the main server so you can do this when no one is on the system. To simulate main server failure it is suggested you simply go to network connections and right click the LAN interface and click on Disable. You can enable the same way when you are done. You can shut the whole machine down if you like, but there is really no need. We do NOT recommend unplugging the network cable from the main server. The reason for this is that you need an ARP broadcast to reset switches and NICS to let the network know that the main server is back online. That won’t happen if you unplug and plug in a cable. However, if you restart the PC, or re-enable the LAN interface, that will happen. Once you have disabled the LAN interface on the main server, then in the SOS4WIN Replication Server application, you can simply click on Tools and then click on Failover. This will bring up the Failover Server Control Panel. Select the LAN interface, then select the failed server from the “Select Server Identity to Assume” drop- down list. It will be listed as ServerName-MAIN if you entered it as such in the hosts file as instructed to do in previous instructions. Then check the appropriate failover actions. In this case, we want: Most of the “Failover Actions” are for use when you have a simple file server and thus have not cloned it into a VM. With a VM you only need a few of them checked. You can click on Help in the control panel to read about the various failover actions and when to use what. Since this is a VM you already have the shares needed turned on (because it’s a clone of the original) so you don’t need to check “Publish Shares.” If it is an Exchange Server you will check that. If it’s a SQL server, you will check that. You don’t need “Assume Hostname” because the VM already has the original hostname. You don’t need “Start DHCP”, because if it is a DHCP server you will already have that also by virtue of it being cloned into a VM. You almost never need “Reboot PC.” The option to “Clear 43
  • ARP Caches” probably will not be needed when using a VM, but in the event that any workstations have trouble connecting, you can try using that. Otherwise do not check it. So in our example, if it’s an Exchange Server, all we need to check are: • Assume IP (To take identity of failed server), • Start Exchange Srvr (If this is an Exchange server.) Clicking the Fail-Over button will then initiate the designated failover actions for this machine. Within a few seconds the VM hot standby server will be joined to the real network and will appear to all workstations exactly as the failed server. The failover process checks to make sure that the main server is not on the network. It then adds starts the disabled NIC on the standby VM, which already has the IP and MAC addresses of the main server Then it sends an ARP broadcast to inform all switches and NICS that the hardware address of this NIC now owns the IP address of the main server. At this point you can go to workstations and confirm that all connectivity to the server is working OK. 44
  • Fail Over Procedure for SOS Standby Server (Print this procedure for handy reference and keep by SOS Server) 1. On all workstations, close any applications and files that access the server. If the server has crashed they likely will be “Not Responding.” Using Task Manager kill any applications that will not close normally. 2. Shutdown the Main Server. (or disable the LAN interface. Do not unplug cable) Note: If you are doing a test failover, you will simulate a failed server by disabling the LAN interface in Network Connections. You do not want to just unplug the network cable because you will need to simulate a PC restart (which sends an ARP broadcast) and when you re-enable the interface this will cause an ARP broadcast to be sent. If you only unplug and plug in the cable, you won’t get an ARP broadcast and consequently PCs will not reconnect to the server. Note: When the LAN interface is disabled it will break the NetRAID MIrrorFolder connection, causing data writes held in RAM by the backup server to be written to the disk. Before that it may appear data is not in sync, but it actually is, even though a remote-local compare may not show it. 3. On the SOS Standby Server, initiate the failover sequence as follows: a. In the SOS4WIN application, click on Tools, and then click on Failover. (If a VM is being used, click the failover icon on desktop) b. Click the down-arrow next to Select Interface. c. Select the correct Local Area Connection from the dropdown list. d. Click the Down-Arrow next to the Select Server Identity to Assume. e. Select the Server that has failed. f. Check any boxes for services that are needed to start in failover. g. Click on the Failover button. 4. On the workstations, access programs and insure that everything is working correctly and that recent data is available. If any workstations are have difficulty, right-click the network icon and click repair LAN. If any problems persist restart the workstation. 45
  • Fail Back Procedure for SOS Standby Server 1. On all Workstations, close all applications and files that are accessing the server. 2. On the SOS Standby Server, in the SOS4WIN application, click on Tools, and then click on Failover. 3. On the SOS Standby Server, click on the Restore Identity button. 4. On the Main Server, unplug network cable from main server – however, if you are doing a test failover and you disabled the LAN interface instead of shutting down the server, then you do not need to unplug the cable and you may skip to step 6. 5. Restart the Main Server. After it boots, shutdown any applications that started automatically that pertain to data that was being mirrored. 6. On the Main Server, disable RAID-1 mirroring as follows: a. Double-click the MirrorFolder Icon in the tray. b. Change “Mirrors For” to “All Sources”. c. For each destination listed in the bottom half of screen, right-click and select “Disable.” d. File, Close, Yes to save changes. Disabling RAID-1 is important! If you don’t do this you risk overwriting new data written to the backup server with old data from the main server. Also shutdown any applications that started automatically that pertain to data that was being mirrored. 7. On the Main Server, If SQL data was being mirrored, turn off SQL service also. If any other service or application is on or open that is related to data that was being mirrored, turn it off as well. 8. On the Main Server, plug the network cable back in if it was unplugged, or enable the LAN interface if it was disabled. 9. On the SOS Standby Server, insure that SQL services are off. The SQL services should have automatically shutdown during Identity Restore. You should get an onscreen message reporting that. Also insure that any other services related to any mirrored data are off as well. 46
  • 10. On the SOS Standby Server, (on Host if VM used) in the SOS4WIN application, in the left- hand windowpane, right-click on a server share and right-click on Compare Local and Remote Data. The SOS Split-Compare screen that comes up will show the data on the Main Server and on the Standby Server. Click on the Unequal button at the top of the screen to show the unequal files between the systems. Then using the Synchronize-to- Right (or left) buttons at the top of the screen, synchronize the data from the Standby Server to the Main Server. Be careful not to sync in the wrong direction. After the data on the systems is in sync, do a View, Full-Refresh to insure that everything disappears from the screen, which indicates that everything is in sync. The tutorial-demo gives a good visual demonstration of this – just click Tutorial from the Help Menu. Note: it is important that data is in perfect sync before starting MirrorFolder service as outlined in the next step. 11. On the Main Server, turn on SQL Also turn on any other services that you turned off in step 7. 12. On the workstations, access programs and files from the workstations and insure that everything is working correctly. If any workstations are have difficulty, right-click the network icon and click repair LAN. If any problems persist restart the workstation. 13. Insure that the new data that was entered on the backup server when in failover mode is now on the main server. If data is intact, then proceed to step 14. 14. On the Main Server, enable RAID-1 mirroring as follows: a. Double-click the MirrorFolder Icon in the tray. b. Change “Mirrors For” to “All Sources”. c. For each destination listed in the bottom half of screen, right-click and select “Enable.” d. File, Close, Yes to save changes. Note: If MirrorFolder presents an error that it cannot sync a file, do this: 1. Insure SQL is off on Standby Server. 47
  • 2. Turn off SQL on Main Server 3. Click Retry on the MirrorFolder error message. 4. Turn on SQL on Main Server (if retry was successful.) Congratulations! You have now successfully completed installation, configuration and testing of SOS Standby Server with virtual machine failover. If we can be of assistance we would be glad to help so please don’t hesitate to call or email. We welcome your feedback on our product. We enjoy the positive comments and we appreciate constructive criticism. It is your feedback that helps us to constantly improve our product. Need Help? Contact Us! sales@sosstandbyserver.com 480-430-7780 48
  • Section 3 Cloning Existing Virtual Machines to Standby Server The instructions in Section 1 above are for creating a virtual machine out of an existing physical machine. But what if your existing servers are already virtual? In such a case you will still use the same procedures in Section 1, except that you don’t need to run the VMware converter to make a clone VM of the machine. External Drives When backing up an existing VM, you don't have to run the converter to make the VM files, as they already exist. You simply need to copy them off to the Host of the backup server. When backing up virtual machines, speed is of the essence. The best way to do this is to shutdown the VM and then copy the entire data store off to the backup server. You can do this while the machine is in use if necessary, by using the SOS File Access Manager, however it would be better to have the VM shutdown during the backup. Either way, you want the backup to happen as quickly as possible. Even if you do it while the machine is up, there is considerable overhead on the machine while backing up the Virtual Machine Disk (VMDK) file and you want to get that done fast. If you simply send the file over the network to the backup server the transfer will be take a while, depending on the size of your virtual machine. We are talking hours. You can cut that time to a fraction by sending the file to an attached eSata drive. Thus, there is one piece of optional hardware that you might want to consider: Instead of sending the files through the network, you might want to use an externally attached eSata/USB drive for storing your VMware files. That way you can attach your external drive directly to your source server. Since the VMware files can be large you are going to want the higher speed of copying locally. If you have a second internal drive, I suggest you copy them from the datastore to the other internal drive. You will still have to copy them again, over to the standby server, but once you get them copied out of the datastore, you can restart your VM and copy them over at your leisure. If you opt for the external drive approach, you will want to use eSata rather than USB. eSata is much faster than USB. USB runs at 400 Mbs while eSata transfers at 3 Gbs – about 8 times faster. Most external USB drives have an eSata port. You will need to install an eSata card in your main server and also one in your failover machine. You can get an eSata card at any CompUSA, Fry’s Electronics, etc. Don’t forget to buy an eSata cable. Plug the card into a PCI slot and you are ready to go. The eSata setup is optional. If you are going to simply transfer via the network instead of sending to eSata, we suggest that you have Gigabit Ethernet, as 100 Mbit Ethernet would be quite slow. Of course if you are only going to replicate once at 49
  • night, speed may not be that much of an issue for you. If you have the eSata setup, you can rapidly copy the VMD files to the external eSata drive and then move the drive to the backup server and quickly copy them from there to the datastore location. Step-by-Step Instructions 1. On Backup Server Host: Install VMware server. If you don’t have it, go here, register, and get it for free: (they will give you a code when you download, save that code) http://www.vmware.com/freedownload/login.php?product=server20 On Backup Server Host: After installation launch “VMware Server Home Page.” You may need to create a datastore location for the VM you are going to copy over. The default datastore is C:Virtual Machines. You may want to change this to a drive that will have plenty of space. Of course if drive C is large enough you don’t need to change it, in which case you can skip this step of adding a datastore. To add a datastore: On the right side, look for Add Datastore. Click it. Here you will enter the path to where you want the VMware data files to live. Then create a share (if one doesn’t exist already) so that you can reach the datastore location over the network. (If using external drive, no need to make share) 2. On the Host of the Main Server: If you are not using an external drive but will be transferring your files via the network, then map a drive from the source to the target machine. For example map Z to the root of C on the target machine. (if your VM files reside on another drive, of course map to that. If you are using an external drive, plug it into the main server host machine. 3. On the Host of the Main Server: Shutdown the main server VM. Copy the original datastore files from the main server to either the network share drive or to the external drive. You will copy all the files in the datastore directory associated with that machine. For example: C:Virtual Machines2003 Server >>>>> Z:Virtual Machines2003 Server 4. On the Host of the Backup Server: You may now go to the beginning of Section 2, and proceed with those instructions, skipping steps 7 & 8 . 50
  • Section 4 Optional Methods Copying VM While Its Running: The most reliable method of copying a VM is while it is shut down. Nevertheless, there are times you might want to copy a VM while it is running. For example, 24/7 operations make it difficult to schedule down time. Or perhaps you have already made a copy with the VM shutdown, but for backup purposes you want to just make another copy and you are content with doing it with it up and running, since it is not going to be considered a critical essential “only” copy of the VM. Method 1 – Using SOS Open File Data Replicator On the Host of the Main Server: Open the SOS Open File Data Replicator and configure it to replicate the VMWare files. In this example (screenshot below) the data store is on C. If your files are on another drive, then of course point it to that. If the VM is running, be sure to check “Get Open Files.” This will cause the backup to use Volume Shadow Service (VSS) so that it can backup the virtual machine while it is running. It is better to backup the VM when it is down, so do this if possible. Enter a Job Name. If you click on Schedule, then you easily run this task whenever you want, or set it to run automatically on a scheduled basis. Alternatively, you can click “Backup Now.” If you schedule it, then you may click on the View Schedule button and this will open Task Manager. You may then adjust the replication schedule if you desire. The job in Task Manager will be called the same as you gave it in “Enter Job Name” except that it will have “call-” in front of it. Method 2 – Using SOS4WIN Replication Scheduler On the Host: Use SOS4WIN to configure backup of the VM files on the main server host. SOS4WIN works in conjunction with the SOS Open File Access Manager and will allow you to copy the VM files while they are in use. Method 3 – Using SOS NetRAID On the Host of the Main Server: First copy the VM files over with to the backup server with the main server VM shutdown. Do an SOS Compare to make sure the files are exactly the same. Then Configure NetRAID to replicate the VM from the main to the backup. After NetRAID replication is completed, then you can start the main server VM and let users back on the system. Since all user input goes into the VM, everything that gets written to the VM on the main server will simultaneously be written to the standby server VM. There are advantages and disadvantages to this approach. If you have a hardware failure, you can bring this VM online on the standby and it EVERYTHING will be identical to the main server all data, patches, 51
  • active directory, operating system settings, it will all be completely current. However, if you have a failure due to virus or OS corruption, then your backup VM is going to be just as damaged as the original. Nevertheless, this is a good backup plan to use in conjunction with the method described in Section 2. If you have a server boot failure, you can quickly find out if it is software or hardware by bringing up this mirrored VM. If it starts OK then you immediately know it is a hardware problem on the main server. Important: If you copy a VM while it is up and running it will have “lock files” associated with it. You must delete the lock files before you can start the VM. To do this you must use the batch file utility that we have made for this. Copy c:rsyncremovelocks.bat to the datastore directory. Then make a link to it on the desktop. Now all you ever have to do to remove locks is to double-click this link on the desktop. 52
  • Section 5 Cloning Physical Machines to Physical machines Be aware that cloning physical systems to physical systems of dissimilar hardware can be problematic. It can however, still be done in many cases. But if you desire to clone physical to physical it is best to have hardware that is identical or at least similar. Following are the steps for cloning. If you purchased SOS Standby Server you have three CDs: SOS Standby Server CD and two GhostBuster CDs. If you just downloaded the demo you will not have theses CDs If you wish to try cloning, you will need to download the GhostBuster CD ISO and create two identical CDs with it. The URL to download that is: www.sosstandbyserver.com/download/GBSOSPERM.iso Note: if for any reason the boot CDs don’t pick up your disk drivers and will not work, you may use Ghost, Acronis, or any other disk cloning software to create your duplicate server. If our boot CDs don’t see your drivers and you don’t have an alternative cloning software, then you will have to use the VMware procedure in Section 2. This procedure works best if the backup server and main server have identical hardware. If they are not identical, you can still clone them, but you are going to have to reinstall some drivers. You will want to have the motherboard driver CD for the backup server and any other hardware driver CDs on hand to expedite that process. You will also want to have on hand the server OS install disk. On The Backup Server Insert one of the GhostBuster CDs into the machine that is going to be the backup server. Restart the machine and let it boot up off of the CD (You may have to set the CMOS to allow the CDROM drive to be the first boot device). If you are presented with this screen… 53
  • Enter the password: support You will then be presented with the following menu: Be advised that on all these text menus, selecting an option requires entering the number and then hitting <Enter>. Assuming you have a DHCP server on the network assigning IP addresses, the network card has already been identified by the OS (which is Linux, by the way) and it has received an IP address. If you do not have a DHCP server on the network then you will need to assign a static IP. To do this, select Option 8 from the menu and follow the prompts. When are returned to the main menu, select Option 6 – Receive 54
  • Clone Data Stream Directly From Another PC. You will then see this screen. You can select option 1 or 2. I suggest you use option 2. It is more reliable. Figure on going away for a few hours while it finishes. If you are in a hurry, give option 1 a try. After you select option 2 you will be presented with the screen shown below: Select 2. - Receive Clone Image from Another PC You will then see… 55
  • If your hard disk is SCSI or SATA select 2 – SCSI Otherwise select 1 – IDE. Hit Y… 56
  • On The Main Server… Insert the other GhostBuster CD (both CDs are identical) into the main server. Restart the server and boot off of the CD. You will get the main menu… 57
  • Select Option 2 Select Option 1 58
  • Select SCSI for SCSI or SATA, otherwise, IDE. Enter the IP address of the machine you are going to send the image to. 59
  • Hit Enter Hit any key… The next screen will tell you… “You will not see anything on the screen until upload completes.” You should see the hard drive lights on both machines light up. There is no progress meter. When the hard drive lights quit flashing, the image upload is completed. This process images the entire hard disk, even empty space. It will take a couple hours, or longer, depending on the size of the hard disk and whether you are running 10, 100, or 1000 Megabit Ethernet. The imaging runs quickly on Gigabit Ethernet. 60
  • After imaging is complete, remove the CD from the backup machine and reboot it. It will boot up as an exact image of the main server. If the two machines are not hardware identical, then insert the motherboard driver CD. The OS will begin “Finding New Hardware” as it boots up. Just let it search the CD for its drivers. You may have to go through a couple of reboots to get all the drivers installed. Check Device Manager when your done to make sure all hardware is recognized. Note: Do not bring the machine onto the network until you have changed the IP address. You don’t want it to conflict with the main server. Keep the network cable unplugged until the IP is changed. If The Cloned PC Won’t Boot… If the PC receiving the cloned PC does not have the same motherboard chipset, it is likely that the machine will blue-screen when booting after the image process. To fix this, insert the install CD for the operating system that was cloned. Reboot the machine and do a “Repair Install” from the CD. This is usually the second repair option. Do not take the first repair option that says “Recovery Console. Running the repair install will reinstall the OS without disturbing the existing applications or configurations. After that install any service packs necessary to get it to the same level as the main server. Then install any hardware drivers, if necessary. IP Address NOTE: DO NOT CHANGE THE HOSTNAME – SQL type programs and Exchange may break if you change the machine name on the backup server. You will change the IP address in all cases. Do not attempt to change the name of Domain Controllers either. Change the static IP address on the backup server. If you cloned, it will have the same address as the main server that you cloned from. In all cases you will change this so that the Standby Server has a unique address. Give it an address that is on a different subnet than the rest of your network. The reason will be explained below. For now just do it. Let’s assume, for example, that your network has addresses of 192.168.1.x. You will give your standby server an address such as 192.168.2.x, or 192.168.3.x. It doesn’t matter what subnet, so long as it is one you are not using for anything else. Now go to Section 2, Step 7. Follow all procedures there, understanding that procedure said to be done on “Standby Server VM” will be done on the physical standby server. 61
  • Section 6 Configuring SOS4WIN for Simple Server Failover As mentioned in a previous section, some file servers do nothing more than provide the availability of network shares. These simple file servers are not domain controllers, do not run DHCP, DNS, Exchange, SQL or other complex server applications. In such an environment there is no need to do the work of setting up virtual machines. This section details setup for simple server failover and gives additional details concerning the operation of the SOS4WIN Replication Server application. Note: It is possible to provide failover for SQL using the simple server failover method outlined in this section. However you may be better off using the VMware procedure outlined in Section 2. If you are running SQL and you are going to use the method in this section, then you will need to install the SQL engine and application exactly as it is installed on the main server. If you are running Exchange you must clone the machine as in Section 2 or Section 4. Install SOS Standby Server Download it from here: http://www.sosstandbyserver.com/trialform.htm Run winsetup.exe to begin the installation process. After installation run SOS4WIN Replication Server from the desktop or from the Start/Program Menu. It will issue a code and ask for a response code. If you have purchased the product call Swarbrick Software at 480-430-7780, give us your machine code and we will give you a response code that will permanently activate the product. If you have not purchased, you may enter DEMO and the product will run for two weeks. Important: After launching SOS Replication Server, click on Options – Settings, and then click on OK. This will initialize the program’s INI files. You can enter whatever changes you want in Settings later, for now you are merely opening and closing settings to initialize all INI files. DO NOT FORGET THIS STEP – INITIALIZE INI FILES NOW. After launching the application it is recommended that you go to the Help menu and click on Tutorial. This will give you good visual overview of how this application works. Identify Data To Backup Identify the data on the main server that you want to backup. The SOS software works by backing up network shares, so you need to share the data you want to backup. It is 62
  • likely that the data locations are already shared, but if not, share them. It is possible to use administrative shares such as ServerNameC$ and you can have unlimited subdirectories under that such as ServerNameC$SomeDirectorySubDirectory, etc. So if you don’t want to create additional shares you don’t have to. Make a note of where the data locations are and what share name is used to access them. Note: Do not replicate the entire C drive! You do not want to replicate, for example: ServerNameC$. This would cause you to replicate the entire C drive including the Windows directory. Most server boot failures are the result of a corrupted operating system. If you replicate c:windows you are going to replicate any OS corruption that may occur on the main server. If you do that your standby server will be in the same non-bootable state as your main server, which of course defeats the whole purpose of a standby server. Therefore never replicate the windows directory. If you do replicate all of C$ be sure to add c:windows as an exclusion. It is recommended that you only replicate specific data directories, such as ServerNamec$DataSubData - etc. Configure SOS On Backup Server Launch SOS Replication Server on the backup server. Select Options. Select Setup New Mirror. UNC Path is checked. Click Next. 63
  • In UNC Path enter the path to the data to be backed up, for example: ServerNameC$Program FilesACMESQLData or - ServerNameShareName In Group Name, enter whatever description makes sense to you. In the Authentication fields, enter credentials that have administrative rights on the main server. In the Domain Name Field you can enter either the actual domain, if you are on one, or you can enter the machine name of the server you are backing up. If you enter the machine name, make sure the user exists as a local user on the main server. In other words, you can use domain credentials, or local credentials. Click Next 64
  • Mirror Path: This setting is very important if you are running an application server. If this data is application server data, such as SQL or Exchange, then that data must be backed up to the identical location on the backup server, because that is where the application is configured to look for its data. So you would want to change the Mirror Path to be identical to where the data is on the main server, for example if you backed up data from: ServerNameC$Program FilesACMESQLData You would want to set the Mirror Path to: C:Program FilesACMESQLData Note: The program will try to append the machine name to the path to make it unique. Manually change this by hand by typing in the correct path if this happens. Note: If you change the mirror path from the default, you will need to manually publish any windows shares you will need in failover, as they will not be automatically shared in failover. Check the Enable Archiving checkbox. This will make a duplicate copy of the data every day, for as many days as you specify, up to seven days. It is recommended you turn this on if you have enough disk space. The drop-down list goes up to only 7 days, but if you want to archive more than this you can just type in whatever number of days you want. There is no limit. It is recommended that you stagger the archive times if you have lots of shares. For example if you have 10 shares to backup, you don’t want them all to begin archiving at exactly midnight. Stagger their start time a bit so as to avoid overloading the server with multiple copy tasks all going off at once. Click Finish. Your backup share will appear in the left hand windowpane of the application. If you have more data locations to backup, repeat the process. You can backup as many servers and workstations as you have on your network. 65
  • Dealing With SQL In order to backup data from SQL while it is in use, the Open File Access Module must be used in order to allow you retrieve open and locked data. The SOS Open File Access Module (FAM) will be installed on both the main server and on the backup server. The SOS4WIN Replication Server application on the backup server PULLS data from Windows shares. The SOS Open File Access Module (FAM) is “Network Aware,” which means that the backup and the main server FAM modules “talk” to each other. (Only one license purchase of the File Access Module is necessary for this) This allows the SOS application to “pull” the data so that it can get the open-locked files with out any problem. SQL on Backup Server You must install the SQL application exactly as has been done on the main server. (Note: Exchange cannot be installed on the backup server – Exchange can only be done by cloning) Again, it is recommended that if you have an application server such as SQL that you clone the main SQL server into a VM and follow the directions for VMs given above in Section 2. It is possible to do SQL without using a VM. It is your choice. We recommend using a VM, but the software can be configured to work either way. Exchange Server Failover There is a method for setting up failover for Exchange without the use of VMs. If failover for Exchange is desired without using VMs, then the backup server must be a physical clone of the main Exchange server as described in Section 4. The Exchange server is then brought up into “Safe Mode with Networking.” This will keep its services off and 66
  • prevent it from interfering with the main Exchange server. The mail stores are kept in sync with SOS. When failover is desired, reboot the Exchange server and bring it up in regular mode, then execute failover so that it will take the IP address of the main server. We believe that if you have Exchange you are probably better off using the procedure in Section 2. SOS NetRAID If you the SOS4WIN application does not provide replication in a timely manner (which may be the case if you have many gigabytes of data) then you may use the SOS NetRAID driver. This will provide instant replication of data. Whenever data is written to the server hard disk, it will be simultaneously written to the standby server. For more information and for the setup procedures see Section 6. Note: The NetRAID driver runs as a service. Some servers may be running other drivers which may not be written to approved standards. These may conflict with the NetRAID driver. If you have any issues booting the server after installing the NetRAID driver, reboot, hit F8 and select “Last Known Good Configuration.” Then call us for technical assistance. Install Backup Scheduler On Main Server This step is only necessary if you decide that you want to push the data on the main server to the backup server. It is necessary to push the data if you’re doing Exchange server or SQL. This is because the open file manager will not function on the backup server if it is in safe mode, consequently you must push the data from the main server with the scheduler so that it can use the open file module on the main server. So, in this case you will need both the Backup Scheduler and Open File Manager Module installed on the main server. In this case proceed as follows; otherwise you may skip to Step 10. The setup program for the Backup Scheduler will be found in C:RSYNC on the backup server. It is SetupScheduler.exe. Put that file on the main server and run it to install the SOS Backup Scheduler. Update: There are now three version of the scheduler. Their respective installation programs are located as follows: 67
  • SOS Offsite Replication Scheduler for Servers: c:rsyncSetupScheduler4Servers50.exe SOS Offsite Replication Scheduler for XP: c:rsyncSetupScheduler50.exe SOS Offsite Replication Scheduler for Vista c:rsyncSetupSchedulerVistas50.exe Install Open File Manager on Main Server After the backup scheduler is installed go to Start/All Programs/SOS Backup Scheduler and select Install SOS Open File Access Manager. Install Open File Manager on Backup Server Go to Start/All Programs/SOS Backup Scheduler and select Install SOS Open File Access Manager. Note: When you purchase the open file module you will receive two codes, one for each server. You do not have to buy two copies – one purchase gets you two licenses. Configure Backup Scheduler on Main Server Note: This step is optional The purpose of the backup Scheduler is to push the data from the main server to the backup server at scheduled intervals in conjunction with the Open File Manager. This will allow you to backup open and locked database files. However you DO NOT have to use the scheduler to push the data. The backup server can pull the data with the SOS4WIN Replication Server Interface. The Open File Module is Network Aware and will, in most cases, allow you to backup locked files in this manner. Update: The addition of the QuickSync feature now allows you to schedule the replication of data to be pulled from the backup server at specific times. Note: If you do not want to use the Backup Scheduler you may skip to “Activating SOS4WIN on the Backup Server” now. 68
  • On The Main Server… From the Tools Menu in Explorer, select Map Network Drive. Map a drive to the location you shared in Step 7. Check “Reconnect at logon.” In the above example we used the sharename SQLData, so you would enter ServerNameSQLData in the folder box. Take note of the drive letter. Which is Y, in this case. Click Finish. Now launch the SOS Backup Scheduler: Start/Programs/SOS Backup Scheduler/SOS Backup Scheduler. 69
  • In the Source Directory select the actual directory location where the database lives. If you get any other directories in the Backup List window by accident, just click on them and they will be removed from the window. Make sure when you are done you only have what you want in the backup list window. Select Y: in the Destination Drive and make sure it is reflected in the Destination Directory window. You do NOT need to checkmark Use OFM and Use Rsync. (Ignore the fact that its checked in the picture above) Type in a jobname (8 characters or less) – whatever you want to call it. Then click on Schedule Backup. Then click on View Schedule. This will open the Scheduled Task folder as shown below. Notice that the jobname SQLData is scheduled. You can double click on SQLData and select the Schedule Tab and change the schedule to be whatever you want – every minute, every hour, every three hours, daily, etc. Test it by right clicking on it and selecting Run, and make sure it works OK. Bear in mind that the backup server SOS4WIN application is configured to pull the data from here, and this is configured to push the data. You obviously don’t need both. For that reason you do NOT need to activate the sync on the SOS4WIN application on the backup server for that particular share. It DOES need to be configured there (for failover purposes) but it does NOT need to be actively syncing. Activating SOS4WIN on the Backup Server Important Note: You must edit the hosts file on the standby server and place entries for any machines you are backing up that you will want to provide failover services for. FAILOVER WON’T WORK IF YOU DON’T DO THIS! 70
  • Typically the hosts file is located in: c:winntsystem32driversetc UPDATE: There is now an entry in the Start / All Programs / SOS Standby Server / Edit Hosts File to let you easily do this. The entry you put in for each machine would be in the format in the examples below: 192.168.0.34 MainServerName 192.168.0.35 AnotherServerName If this is not done, failover will not work for those machines that are left out of the hosts file. Launch SOS4WIN Replication Server… On the backup server launch SOS4WIN Replication Server. You will find an icon on the desktop and also a menu item in All Programs / SOS Standby Server that will allow you to launch SOS4WIN. Windows Permissions You are now ready to begin copying data to the backup server. Before you start this process you need to think about Windows Permissions. Most people handle permissions on a file server through Windows Share Permissions. When the backup server goes into failover mode it is going to share the Windows Shares with permissions set to allow access for Everybody. Since people are normally only mapped to areas they have permission to anyway, the fact that the permissions are open will not be an issue in most environments. If this is acceptable for the short duration that you operate on failover mode, you need not change anything. However for many this will not be acceptable and tighter security in failover will be desired. You may copy the Share Permissions from the main server to the backup server. This is easily accomplished via the Tools Menu. From the Tools Menu select Copy Share Permissions. You will be prompted for the name of the server you wish to copy the permissions from. This routine will automatically copy all the Share Permissions from all the Shares that you have configured SOS to back up. (Note: If you are not in a domain environment the name of the person’s credentials will not be added to the share permissions, only the security identifier will show up.) For those who do not use Share Permissions to control access, but instead use Directory Permissions, you will want to do your first initial sync of data in a special way so that the Windows Directory Permissions (ACL’s) are copied over. 71
  • To do this so that the ACL’s are copied over with the files, do NOT start sync in the normal manner. Instead, right-click on each share and select “Compare Local And Remote Data.” Then click on the “Synchronize To Left” button and follow the prompts. This will copy all the data for that share from the main server to the backup server. Doing the initial copy in this manner will bring over all the ACL Directory Permissions. You will need to do this for each share you have defined. You only need to do this once, and then after that you can sync in the normal manner. After this procedure you will have the same Directory Permissions on the backup server as on the main server and in failover directory access will be exactly the same as on the main server. If you have already synced the data in the normal manner, and you want to bring the Directory ACL’s over, then delete the backed up data and directories on the backup server and start over doing the sync as above to get the directory permissions copied. In the SOS4WIN application you may now activate sync in the normal manner. To turn on syncing on all shares, select Options/Start Mirroring. If you have an application data location defined, right click on that share and select Deactivate Mirroring. It isn’t necessary to have that one syncing, as the data is being pushed over by the SOS Backup Scheduler. The Workstations Any drive mappings on workstations need to be changed from mapping with machine names to mapping with IP addresses. For example If they map to a server called SERVER01 and that server’s IP address is 192.168.1.10, then instead of the workstations being mapped with SERVER01SomeShare You would instead map them with: 192.168.1.10SomeShare. (UPDATE: If you are using a VM on the backup server, then you don’t have to map with IP address. The VM will have the same name.) 72
  • This can easily be done by simply changing the user logon scripts on the Domain Controller. If you are not in a domain environment, then the drive mappings must be done locally on each workstation. You must go to each workstation and remap them using IP address. This is necessary for failover to work. If you are in a domain environment, the easiest way is to simply make the change in the user logon script. Note: Login Scripts are located in c:windowssysvolsysvol<domain name>scripts If you are not familiar with logon scripts, here are a couple of websites that will tell you what you need to know. http://www.amset.info/loginscripts/implementation.asp http://support.microsoft.com/kb/258286 Configure AutoLogon and AutoSync You might want to make some configuration changes so that SOS Standby Server will start syncing automatically when the standby server is rebooted. The very first thing you should have done before installing is to make a specific user that will be used to logon to this PC to run the SOS application. Do not use administrator. Instead you want to always logon as a user such as SOSBackup and then give that user admin rights. Always log onto the console as this user when installing and configuring SOS. This is the user that will be configured to autologon. This is important because if you configure the administrator as the SOS user, then if anyone does a remote desktop to the PC it will automatically start a second instance of SOS, and we don’t want that to happen. You also want to make sure that the SOSBackup user is a domain logon, not a local logon. Logged on as SOSBackup domain user, do this… 1. Start / All Programs /SOS Standby Server / Install TweakUI 2. Start / PowerToys For Windows XP / Tweak UI 3. Click the + next to Logon 4. Click AutoLogon 5. Check the box: “Log on automatically at system startup” 6. Enter the SOSBackup user into the user name field. 73
  • 7. Click set password button and enter the password. 8. Click OK 9. Launch SOS Replication Server (if not already started) 10. Click Options / Settings 11. Click the General Tab 12. Click checkbox “Start synchronizing when SOS4WIN starts. 13. Click OK 14. Reboot Server and insure that it auto logs on and starts syncing. Pre-Publishing Shares Although failover mode will publish network shares, you may want to pre publish these share to insure they have the correct permissions set. To do this, In SOS4WIN on the standby server, click on Tools and then “Copy Share Permissions.” This will publish the shares. You can copy share and ACL permissions in this routine if you want to. The final question will ask you if you want to leave the shares published. Answer yes. DHCP Server If the main server is not running a DHCP server, skip this step. If the main server is running DHCP and you installed an OS from scratch, then setup a DHCP server on the backup machine and configure scope as instructed below. If the main server is running a DHCP server, and we cloned the main server, then there will be a DHCP server running on the backup server that is issuing the same IP scope as the main server. This is not acceptable and will cause duplicate IP addresses on the network. ( NOTE: This is not a problem if the standby server is a VM or is sequestered into a different subnet. Ignore the following instructions if that is the case. To prevent this from happening you must change the scope of the IP addresses assigned by the backup server. You do not want to simply turn off DHCP on the backup server, as you will need the DHCP server in failover mode. Here is an example of how to set this up: If you have 90 workstations on the network, set the scope on the main server as: 192.168.0.2 – 192.168.0.100 and on the backup server as: 192.168.0.101 – 199 74
  • This way both DHCP servers can be operational and they won’t step on each other. It won’t matter which server answers a DHCP request. Configuring your DHCP server is done from Start/Control Panel/Administrative Tools/DHCP as follows: Right click on “Scope” and select Properties. 75
  • Change the scope to be as you desire, as specified in the above example. Do this on both the main server and the backup server so that they won’t interfere with each other. Configure & Test Failover 1. Shutdown the main server. (simulating server down) 2. Stop Sync on the backup server. 3. Select Tools/Failover on the SOS4WIN Application. 4. Select Interface, Server Identity to Assume, and click on Fail-Over Button. 5. Backup Server will then automatically add the IP address of the main server to the NIC of the Standby Server and it will then share all data with identical share names as were used on the main server. 6. From a workstation, confirm that all mappings are still there and that data is accessible as though the server were not really down. If not, reboot workstation and try again. 76
  • NOTE: NEVER close the Fail-Over Control Panel by Xing out of it. Always use the Cancel button provided. This module allows you to select the actions that occur during failover. To assume the identity of a failed server, simply select the network interface from the drop down list, and then select the failed server from the drop down list. Next, you select the actions you wish to take place in failover mode. Make certain the failed server is turned off or its LAN interface disabled before proceeding. If you are merely testing failover it is suggested that you disable the LAN interface in Network Connections. Do not just unplug the cable as the server needs to make an ARP broadcast when it comes online and restarting the Network Connection will accomplish that. Failover Actions Normally you will check only three boxes: Assume IP, Publish Shares & No VM. You will then click the Fail-Over button. The SOS Standby Server software will then add the IP address of the failed server to the network card and it will share the backed up data with the same share name as was used on the failed server. The software will then send an ARP broadcast to the network so that all devices will know that the MAC address of the standby server's LAN card now owns the IP address of the failed server. For this to work correctly the setup procedures as described in the manual must be followed correctly. Specifically, you must put the names and IP addresses of any servers being mirrored into the hosts file of the standby server. Note: Be sure click No VM, since VMware is not being used. 77
  • Also during setup you should have unmapped all workstations and remapped them using IP address. For example, you would change ServerNameSharename to be 192.168.1.10ShareName. This can easily be done by simply changing the logon script on the server. If any workstations map locally and not by logon script then those workstations will need to be unmapped and remapped with IP. ASSUME MACHINENAME -- If your server runs software that is machinename dependent you can select this option and the standby server will also take the name of the failed server. This will cause the standby server to reboot when entering failover, as a machine rename requires this. START DHCP SERVER -- If the failed server was providing DHCP then you can check this in order to have the software start the DHCP server on the standby server when it goes into failover mode. You will of course of had to setup the DHCP server parameters in advance on the standby server and have set the DHCP server service to manual, rather than automatic. The manual has details on this procedure. ASSUME MACHINE NAME & REBOOT - normally not needed but there if you want it. CLEAR ARP CACHE -- Allows you to designate to clear ARP caches on all workstations during failover and restore. This is required on 64 bit 2008 Server and may be helpful in some environments if workstations do not recognize the standby server when it comes online. No VM - Reboots – Be sure to check this when configuring for Simple Server as VMware is not being used. If you don’t check this and you are not using VMWare then failover will not work properly. When Not To Publish Shares In some situations you will not want to select Publish shares. An example of when this would be the case would be where the standby server has client/server application software (such as SQL) installed that requires you to change the default mirror location. If you have changed the default mirror location in the SOS4WIN application then the data will not get shared in failover. In this case you would manually share the correct data location with the correct sharename (i.e., same sharename as on the main server) beforehand and merely leave it shared. You would then not check Publish Shares, as that would be unnecessary since you have manually pre-shared the data locations on the standby server. If you choose to pre-share data locations on the standby server, be sure to assign the same sharename as on the main server and assign appropriate user rights to the share. To manually pre-share, you may right click the share in the SOS4WIN application and select Explore Share, which will take you to the data location in Windows Explorer, then right-click and select Sharing and Security. 78
  • Restoring Identity First select the Interface and server from the drop down lists and then click Restore Identity. The software will then release the IP address it assumed. If shares were published it will un-publish those shares. If the DHCP server was started, it will be stopped. If the machine was renamed, it will be renamed back to its original name and the machine will reboot. Reboot only happens if a machine rename is involved. Syncing Data Back If you have operated in failover mode and users have been saving data to the standby server, you will need to sync this new data back to the main server before allowing users back on the main server. Right-click each share and select “Compare Local and Remote Data.” The split window appears. In the example below you see that the standby server on the left has new data that is not on the main server. 79
  • Now click on the unequal button near the top left corner. The All data will disappear except what is not equal. You will see in the standby server window all the files that are new or have been modified. You will then click on the yellow Sync-to-Left Arrow in the top middle of the application. 80
  • Another window will pop up showing you what it is going to copy. You will click start to begin the copy. After that is complete you may do another compare and click the unequal button and insure that everything disappears from both windows. You are then sure that all data is the same. Repeat this procedure for each data share. Below is a procedure you can print out and keep near your servers so that you will have a handy failover and fail-back procedure ready when you need it. 81
  • Fail Over Procedure for SOS Standby Server (Print this procedure for handy reference and keep by SOS Server) 5. On all workstations, close any applications and files that access the server. If the server has crashed they likely will be “Not Responding.” Using Task Manager kill any applications that will not close normally. 6. Shutdown the Main Server. (or disable the LAN interface. Do not unplug cable) Note: If you are doing a test failover, you will simulate a failed server by disabling the LAN interface in Network Connections. You do not want to just unplug the network cable because you will need to simulate a PC restart (which sends an ARP broadcast) and when you re-enable the interface this will cause an ARP broadcast to be sent. If you only unplug and plug in the cable, you won’t get an ARP broadcast and consequently PCs will not reconnect to the server. Note: When the LAN interface is disabled it will break the NetRAID MIrrorFolder connection, causing data writes held in RAM by the backup server to be written to the disk. Before that it may appear data is not in sync, but it actually is, even though a remote-local compare may not show it. 7. On the SOS Standby Server, initiate the failover sequence as follows: a. In the SOS4WIN application, click on Tools, and then click on Failover. (If a VM is being used, click the failover icon on desktop) b. Click the down-arrow next to Select Interface. c. Select the correct Local Area Connection from the dropdown list. d. Click the Down-Arrow next to the Select Server Identity to Assume. e. Select the Server that has failed. f. Check any boxes for services that are needed to start in failover. g. Click on the Failover button. 8. On the workstations, access programs and insure that everything is working correctly and that recent data is available. If any workstations are have difficulty, right-click the network icon and click repair LAN. If any problems persist restart the workstation. 82
  • Fail Back Procedure for SOS Standby Server 15. On all Workstations, close all applications and files that are accessing the server. 16. On the SOS Standby Server, in the SOS4WIN application, click on Tools, and then click on Failover. 17. On the SOS Standby Server, click on the Restore Identity button. 18. On the Main Server, unplug network cable from main server – however, if you are doing a test failover and you disabled the LAN interface instead of shutting down the server, then you do not need to unplug the cable and you may skip to step 6. 19. Restart the Main Server. After it boots, shutdown any applications that started automatically that pertain to data that was being mirrored. 20. On the Main Server, disable RAID-1 mirroring as follows: a. Double-click the MirrorFolder Icon in the tray. b. Change “Mirrors For” to “All Sources”. c. For each destination listed in the bottom half of screen, right-click and select “Disable.” d. File, Close, Yes to save changes. Disabling RAID-1 is important! If you don’t do this you risk overwriting new data written to the backup server with old data from the main server. Also shutdown any applications that started automatically that pertain to data that was being mirrored. 21. On the Main Server, If SQL data was being mirrored, turn off SQL service also. If any other service or application is on or open that is related to data that was being mirrored, turn it off as well. 22. On the Main Server, plug the network cable back in if it was unplugged, or enable the LAN interface if it was disabled. 23. On the SOS Standby Server, insure that SQL services are off. The SQL services should have automatically shutdown during Identity Restore. You should get an onscreen message reporting that. Also insure that any other services related to any mirrored data are off as well. 83
  • 24. On the SOS Standby Server, (on Host if VM used) in the SOS4WIN application, in the left- hand windowpane, right-click on a server share and right-click on Compare Local and Remote Data. The SOS Split-Compare screen that comes up will show the data on the Main Server and on the Standby Server. Click on the Unequal button at the top of the screen to show the unequal files between the systems. Then using the Synchronize-to- Right (or left) buttons at the top of the screen, synchronize the data from the Standby Server to the Main Server. Be careful not to sync in the wrong direction. After the data on the systems is in sync, do a View, Full-Refresh to insure that everything disappears from the screen, which indicates that everything is in sync. The tutorial-demo gives a good visual demonstration of this – just click Tutorial from the Help Menu. Note: it is important that data is in perfect sync before starting MirrorFolder service as outlined in the next step. 25. On the Main Server, turn on SQL Also turn on any other services that you turned off in step 7. 26. On the workstations, access programs and files from the workstations and insure that everything is working correctly. If any workstations are have difficulty, right-click the network icon and click repair LAN. If any problems persist restart the workstation. 27. Insure that the new data that was entered on the backup server when in failover mode is now on the main server. If data is intact, then proceed to step 14. 28. On the Main Server, enable RAID-1 mirroring as follows: e. Double-click the MirrorFolder Icon in the tray. f. Change “Mirrors For” to “All Sources”. g. For each destination listed in the bottom half of screen, right-click and select “Enable.” h. File, Close, Yes to save changes. Note: If MirrorFolder presents an error that it cannot sync a file, do this: 5. Insure SQL is off on Standby Server. 84
  • 6. Turn off SQL on Main Server 7. Click Retry on the MirrorFolder error message. 8. Turn on SQL on Main Server (if retry was successful.) 85
  • Fail Back Procedure for SOS Standby Server (Print this procedure for handy reference and keep by SOS Server) 1. On all Workstations, close all applications and files that are accessing the server. 2. On the SOS Standby Server, in the SOS4WIN application, click on Tools, and then click on Failover. 3. Click the down-arrow next to Select Interface. 4. Select the correct Local Area Connection from the list. 5. Click on the Restore Identity button. 6. Restart the Main Server. 7. On the SOS Standby Server, (on Host if VM used) in the SOS4WIN application, in the left-hand windowpane, right-click on a server share and right-click on Compare Local and Remote Data. 8. The SOS Split-Compare screen that comes up will show the data on the Main Server and on the Standby Server. Click on the Unequal button at the top of the screen to show the unequal files between the systems. Then using the Synchronize-to-Right (or left) buttons at the top of the screen, synchronize the data from the Standby Server to the Main Server. Be careful not to sync in the wrong direction. After the data on the systems is in sync, do a View, Full-Refresh to insure that everything disappears from the screen, which indicates that everything is in sync. The tutorial-demo gives a good visual demonstration of this – just click Tutorial from the Help Menu. 9. Access programs and files from the workstations and insure that everything is working correctly. If any workstations have difficulty, restart them. 86
  • Fail-Over…(Automatic) You may select one machine to monitor and automatically take over its identity if it should fail. UPDATE: Automatic failover is not yet coded to work with VMs. If you are running in a VM you must do manual failover. This feature will be available very soon as an update. 1. From the Tools Menu select Autofail. 2. Enter the name of the machine to monitor. 3. Enter the interface to use. Typically Local Area Connection. You can check in Network Connections to confirm the name of your LAN connection. The SOS Server will continually ping the server selected. If it should cease to respond failover will be automatically initiated within a matter of seconds. 87
  • Section 7 Miscellaneous Configuration Options SOS NetRAID Similar to a software-only RAID-1 system, the network raid function duplicates individual file I/O requests in memory and sends them to both source and mirror devices at the same time. The uniqueness of this is that it actually is RAID to another PC. For example, if you have a large database file in your source folder and modify only one record in that file using the application interface of that database, the Network RAID driver will modify only that same record in the mirror database file simultaneously, and will NOT copy the entire source database file to its mirror. The advantages of network RAID are that there is no lag time in data synchronization - it happens in real-time and will keep data in sync even if the files are in use and locked. This is because it doesn’t have to actually read the file, but catches data writes in memory before they are written to disk and sends them to both the local disk and the network location at the same time. This is an excellent option to use for SQL or Exchange data. Install Replication Scheduler and SOS NetRAID on Main Server: Download from here. You would select the first link normally. If anyone is using vista or XP as a server then you would select the second or third link. When are asked during the install if you want to install SOS NetRAID drive answer yes. Server OS: www.sosstandbyserver.com/download/SetupScheduler4Servers.exe Vista OS: www.sosstandbyserver.com/download/SetupSchedulerVista50.exe XP OS: www.sosstandbyserver.com/download/SetupSCheduler50.exe Configure SOS NetRAID First, if you have not yet done so, map a drive from the main server to the destination. on the Standby Server VM. Be sure to map with IP address. Launch the SOS Data Replicator – Start / All Programs / SOS Open File Replication Scheduler / SOS Backup Scheduler. Then using the Network RAID function of the backup scheduler, you can configure RAID synchronization from the main server to the HOST. Select the data source in the Source Directory Window, then select the destination in the Destination Directory Windows. The destination will be the drive that you just mapped. The Network RAID will automatically create subdirectories on that mapped drive as the data copies. After you have selected Source and Destination, then click on the Network RAID button. 88
  • All the data will copy initially. After that data writes will occur simultaneous with writes to the main server hard disk. Network RAID Repeat this process for all data on the main server that you wish to replicate. After you have completed you can launch the SOS NetRaid Mirror Folder application to view what you have setup. Do this: Start / All Programs / SOS Standby Server / SOS NetRAID MirrorFolder. Be certain all your shares are in the list and that they are set to mode RAID-1. 89
  • Note: The NetRAID driver runs as a service. Some servers may be running other drivers which may not be written to approved standards. These may conflict with the NetRAID driver. If you have any issues booting the server after installing the NetRAID driver, reboot, hit F8 and select “Last Known Good Configuration.” Then call us for technical assistance. Note: Turn off any antivirus before making the first initial copy of data with NetRAID. Important: Although the SOS NetRAID driver can move data that is written to locked files (because it catches the data before it is written to the file), it cannot actually read and send a locked file. What this means is that you must first get the locked data moved over before the benefits of NetRAID can be used on locked files. This can be done in two ways. You can turn off the SQL or Exchange or whatever service has the files locked. (Alternatively, you could boot up in safe mode with networking, temporarily.) You can then copy the data over to the location on the Standby Server VM. It is best to make this data copy with the associated service off, however if that is a problem, another method can be used to copy the data while the service is running. This is done by using the SOS Open File Replication Scheduler to copy the data. The SOS Scheduler works in conjunction with the SOS Open File Module and will send locked SQL or Exchange data even while it is in use. You do this AFTER you have configured the NetRAID replication, then you use the SOS Scheduler and select source and destination. Then type in a name (8 characters or less), and click on Backup Now. (You do not need to check “Get Open Files.” If the SOS Open File Module is installed you do not need to check that.) After the replication completes you can click on SOS Compare and then click the unequal button and view the split windows to confirm that the data is in sync. After the initial data copy is complete, the NetRAID driver will keep the data in sync. Offsite Backup Configuring Offsite with SOS4WIN As the SOS4WIN Replication Server syncs each share, at the completion of each share, it will then transmit data to offsite, if you have configured it to do so. To configure this, in the SOS4WIN interface do this: Options / Settings / General 90
  • Put a check in the Offsite Backup check box In the Rsync Server Name box, edit the example that is there. The example reads: share@my.rsync-server.com::share/ Change this to something like: SHARE1@64.23.17.43::SHARE1/ Or SHARE1@MyPC.no-ip.com::SHARE1/ Make sure that SHARE1 is in caps, it is case sensitive Note: If the ISP for the receiving Rsync Offsite Server is assigning dynamic ip addresses, then you will want to setup a domain name for the receiving server. This is easily done for free. Go to www.no-ip.com and setup a free account. Then install the Dynamic Update Client, which you can download free from them. You will also find the dynamic update client in C:RSYNCSERVER on the offsite server. The filename is: ducsetup.exe Just run that file to install the dynamic update client. This way whenever your ISP changes your public IP address, DNS servers on the Internet will be notified that your DNS name now points to another IP Address. After you have entered your offsite information in settings, then right click on any share you want to go to offsite, and click on Edit Properties. Then Check the box: Enable / Disable Offsite Mirroring. That share will now go to offsite when it is synced. Configuring Offsite with SOS Backup Scheduler Another client you can use to send data to offsite is the SOS Backup Scheduler. This component allows you to schedule an offsite transmission at a specific time of day, whereas the SOS4WIN Replication Server sends data to offsite continually. Some people prefer to schedule this transmission at specific times, such as at night during off- peak hours. The backup Scheduler can be launched from SOS4WIN. Tools / Schedule Backup will bring it up. You can also run the file C:RSYNCSetupScheduler.exe on the main server and send offsite data transmissions directly from their to your offsite location. You may transmit data to your offsite data receiver via the Internet by simply typing in the Rsync address in the destination window in the form: 91
  • SHARE1@MyRsyncServer::SHARE1/ Be sure to click on HELP in the scheduler and read the entire help file. 92
  • Configuring Your Offsite Receiver To setup an offsite receiver (Rsync server on Windows) do this: 1. Copy c:rsyncSetupRsyncServer.exe to a flash drive 2. Run this file on the offsite server (2000, XP, 2003) 3. From All Programs launch Rsync Server Control Panel 4. Select port 873 5. Click Create Rsync Server You may confirm that the Rsync Server installed and is started by looking in services. Be sure to click on HELP in the Rsync Server Control Panel and read the entire help file. Troubleshooting Offsite Rsync Connectivity If you have any trouble with offsite Rsync transfers, here are some basic troubleshooting tips: Make sure that the Rsync server knows the client machine by name. From the Rsync server, make sure you can ping the client machine by its Netbios name. If you cannot, edit the hosts file on that server, usually located in c:winntsystem32driversetc. Put in the line as IPAddress hostname, like this: 131.127.140.97 TMPWS-PLIN You can test that the Rsync server is functioning by opening a command prompt on the Rsync server and typing: Rsync hostname:: Where “hostname” is the actual hostname of that server. You can type hostname at a prompt to learn what the hostname is. Or you may use the IP address, like this: Rsync 131.127.124.34:: Note that there must be TWO colons immediately following the hostname or IP address. After issuing this command you should see a display of all the Rsync shares on that machine, such as: SHARE1 Share 1 c:rsyncshare1 If the Rsync server is not functioning correctly you will get an error message, such as: 93
  • Rsync: read error: Connection reset by peer Rsync error: error in Rsync protocol data stream (code 12) If the Rsync server is not functioning correctly, check to make sure that the directory exists that you have defined as an Rsync share. You can also check in Control Panel/Administrative Tools/Services and see if the Rsync service is running. You can stop and restart it, or you can remove and reinstall it from the RsyncServer ControlPanel. You can also visually examine the rsyncd.conf file for errors. If everything seems fine on the Rsync server, but you still have trouble transferring data, from the client machine execute the command: Rsync hostname:: Where the hostname is the hostname of the Rsync server. You should get a listing of Rsync shares, just as you did on the server. If you don’t, check to make sure you have basic network connectivity to the Rsync server. Check to see if you can ping it by name. If you can ping it by name, then check to see if you can ping it by IP address. If you can only ping by IP address, simply use the address instead of the machine name in your transfers, or put the IP address and hostname into your clients hosts file. Do not forget to turn off any software firewalls and forward port 873 through any hardware firewalls. Another thing to check is to make sure that the Rsync Client is operating on the same port that the server was originally configured on. If you have doubts concerning which port the Rsync server is configured to, just uninstall the service and reinstall it. You can uninstall the service like this: C:rysyncservercygrunsrv –R RsyncServer QuickSync Feature The QuickSync Feature is available from the Tools menu. Normally the SOS4WIN Replication Server will only bring over changes in files. If you run QuickSync it will bring over the entire file that has changed, but only files that have changed. Depending on network speed, the size and type of data files, one or the other may be more efficient. You can experiment and see which is best in your environment. To stop QuickSync, Select QuickSync, and the Stop QuickSync from the submenu. DO NOT stop QuickSync by closing the QuickSync Window. Always stop QuickSync from the menu. 94
  • You may also schedule the QuickSync feature by selecting Schedule QuickSync from the menu. This allows you to mirror data at specific intervals. This is a popular new feature that was much requested. This allows you to backup during off-peak hours such as at nighttime. The task is placed in the Scheduled Tasks folder. You can quickly get to that folder by selecting Scheduled Tasks from the QuickSync menu. Another method of getting a faster sync with the standard Rsync protocol (not QuickSync) is to configure an Rsync server on the backup server and push the data over from the main server using the SOS Open File Scheduler. This method copies the data significantly quicker. See the section on offsite backup for directions on configuring an Rsync server. File Replication via Distributed File System Another way you can replicate data with SOS Standby Server is by using DFS. In some instances you may want to configure replication using Distributed Files System (DFS). For example, if you have large amounts of data and/or extremely large files you may find that DFS is much more efficient at replication. The standard sync uses the Rsync protocol which may be too slow for your needs. In this case it is suggested that you use DFS. The standby server and any servers being replicated with DFS must be in a domain. If you use DFS, you will still set up your replication in the SOS Replication Server GUI as normal, but you will not turn on the sync. It is suggested that you configure archiving so that you will always have a back up of older data sets. In order to use DFS the main server and the standby server must be members of a domain and DNS must be correctly configured. In most environments this will be the case. It is suggested that you print this document and use it as a step-by-step reference as you configure DFS. To begin, from the SOS4WIN Replication Server, right-click on each share and select “Share Mirror” from the drop-down menu. Then click on the Tools menu and then click Distributed Files System and select Configure DFS Replication. Procedure for 2003 Server DFS Setup (See below for 2000 Server procedure) 1. Right-click on Distributed File System 2. Select New Root 3. Click Next 4. Select Domain Root (Selected by default) 5. Click Next 95
  • 6. Select the domain name of your domain 7. Click Next 8. Click Browse 9. Select the main server (the server that you want to replicate data from) 10. Click OK 11. Click Next 12. Type in a name for this root. (Doesn’t much matter, pick any name) 13. Click Next 14. Click Browse and select the folder to be shared. 15. Click Next, click Finish. 16. Right-click the newly created root, ie, - domainnameshare etc. 17. Select “New Root Target” 18. Click Browse 19. Select the standby server and click OK. 20. Click Next 21. Click Browse and select the folder to share. Even though this says, “folder to share” don’t let this confuse you. What you are doing here is selecting the target for the replicated data to be stored in. This will be the folder where the data will be replicated to on the standby server. This is typically the path: C:SOSMirrorMachineNameSharename. Where MachineName is the name of the main server and ShareName is the share being replicated. This is where you will point to, unless you have changed the default path. You can right-click on any share in SOS4WIN and see what the mirror path is if you need to check to see what it is. 22. Click Next and Finish. 23. Right-click the root, ie, - domainnameshare etc. 24. Select Configure Replication 25. Click Next 26. Highlight main server in Target Window, click Next. 27. Select Custom topology. Click Finish, Click OK to message about Replication. 28. Right-click again on the newly created root, ie, - domainnameshare etc. 29. Left-click on Properties in the drop down menu. 30. Click the Replication Tab. 31. Click Edit and follow steps to remove any filters. 32. Click Customize. 33. Click New 34. In the Connect From window highlight the main server. In the Connect With window highlight the standby server. Click OK 35. In the next window confirm you are replicating from the main to the standby. Then Click OK Twice to exit. (You can set the Priority to High if you wish.) 36. Click Start/All Programs/SOS Standby Server/Set DFS Staging Size. You will now select a Pre Staging Size. A staging space is a portion of the hard disk used as a cache for queuing up data to replicate. You want this size to be set to at least the same size as the data you are backing up with DFS. If your data set is 20 GB, then you need a 20 GB Pre Staging size. 96
  • DFS and Replication are now configured. It make take 30 minutes or more before replication actually starts for the first time. Don’t assume anything is wrong with replication until at least an hour has gone by. Once it is active, replication of any changes will be immediate. In the SOS4WIN GUI it is suggest you leave sync off for any shares that are being synced with DFS, but it is suggested you leave them in the list and have archiving configured. Archiving is always important, because if anything is deleted from the main server it is also deleted from the backup on the standby server. But if archiving is set, you can always retrieve data from the archive, even if it was accidentally or intentionally deleted on the main server. Also, even if DFS is used for all replication, you always want to leave the SOS4WIN application up, as it will not archive if it is not launched. Procedure for 2000 Server DFS Setup As mentioned above, to begin, from the SOS4WIN Replication Server, right-click on each share and select “Share Mirror” from the drop-down menu. Then click on the Tools menu and then click Distributed Files System and select Configure DFS Replication. 1. Right-click on “Distributed File System” 2. Select “New DFS Root”, click Next. 3. Select “Create a Domain DFS Root” (selected by default), click Next. 4. Select the domain name of your domain, click Next. 5. Click on the Browse button. 6. Select the main server from the list. (The main server is the server you want to replicate data from), click OK. 7. Click Next. 8. In this window you will select the windows share that is on the main server that you want to replicate the data from. If that share does not yet exist you can create it here. Normally this share will already exist. 9. Click Next. 10. Type in a DFS root name. It can be anything. You can simply use the share name if you like. 11. Click Next. 12. Click Finish. The newly created DFS Root will appear in the left hand pane of the DFS window. 13. Right-click on the newly created DFT root in the left hand window. 14. In the drop-down menu click on “New Root Replica…” 15. Click the Browse button. 16. Select the standby server, click OK. 17. Click Next. 18. Click the drop-down arrow to the right of the “Use an existing share” window. Now select the share that is the share that was created when you clicked on “Share Mirror” in the SOS4WIN application. This share is the target that replication data will be stored in. It will have been automatically named by 97
  • SOS4WIN in the format: Servername_Sharename, where the Servername is the name of the server the data is coming from. 19. Click Finish. 20. Right-Click the DFS root in the left-hand window of the DFS wizard. 21. Select “All Tasks” / Replication Policy from the drop-down menu 22. You will see the two DFS root folders listed. Highlight each one and click the enable button so that both are enabled. 23. Select the DFS share which is on the main server and click the “Set Master” button. 24. Click OK. DFS and Replication are now configured. It make take 30 minutes or more before replication actually starts for the first time. Don’t assume anything is wrong with replication until at least an hour has gone by. Once it is active, replication of any changes will be immediate. In the SOS4WIN GUI it is suggest you leave sync off for any shares that are being synced with DFS, but it is suggested you leave them in the list and have archiving configured. Archiving is always important, because if anything is deleted from the main server it is also deleted from the backup on the standby server, if it is 2000 server. But if archiving is set, you can always retrieve data from the archive, even if it was accidentally or intentionally deleted on the main server. Also, even if DFS is used for all replication, you always want to leave the SOS4WIN application up, as it will not archive if it is not launched. Troubleshooting DFS DFS Environment Clean up If, when setting up DFS, you get an error message about not being able to create a file that already exists, this can be caused if DFS roots were previously setup and deleted. To fix this, you can clean up the DFS environment by running the following command on the standby server: c:rsyncdfsfix.bat DFS Staging Space Another problem that may occur is that you could find that all of your data does not replicate. For example it may begin replicating the directory tree and inexplicably stop part way through. If this happens check the Event Log of the standby server. In addition to Application, Security and System, you will see that you know have a “File Replication Service” log file. Looking under that you may see an error that says this: “The File Replication Service paused because the size of a file exceeds the staging space limit. Replication will resume only if the staging space limit is increased. The 98
  • staging space limit is 675840 KB and the file size is 823968 KB. To change the staging space limit, run regedit. Click on Start, Run and type regedit. Expand HKEY_LOCAL_MACHINE, SYSTEM, CurrentControlSet, Services, NtFrs, Parameters, and the value "Staging Space Limit in KB".” If you get this error your Pre Staging size is too small. A staging space is a portion of the hard disk used as a cache for queuing up data to replicate. You want this size to be set to at least the same size as the data you are backing up with DFS. If your data set is 20 GB, then you need a 20 GB PreStaging size. DFS Filters Even though you may have removed filters for ~, bak, and tmp files when you set up DFS, you may find that these files still do not replicate. On the domain controller, go into Active Directory Users and Computers. On the View menu click Advanced Features. Expand “System”. Expand “File Replication Service.” Right-Click “Domain System Volume.” Click Properties. You will see “File Filter.” Remove the ~, bak, and tmp filters from this window and click OK. Create another filter such as “*.~null” This is just a bogus filter that won’t actually filter anything, unless you actually have a file with that pattern, which is unlikely. This null filter will force an overwrite of the preexisting filter. It will then take a reboot to put this into effect. Any new files that are ~, bak, or tmp will then get replicated, however the existing files will not replicate until they have been modified in some way. You may use the SOS Compare utility (ToolsSOS Compare) and click on the “Unequals” button and see the bak and tmp files that are not copied over. You can then click the Sync to the left button to bring them over so that you an exact replica of your data set. SDR – SOS Daily Restart Using this feature is completely optional. If you select SDR/SOS Daily Restart from the Tools Menu, a process will be run in the background that will restart the SOS Replication Server every day at 5:00 AM. The only purpose to use this feature would be if you experience any occasional lockup problems with SOS Replication Server. This is unlikely to happen. However if you do experience an application hang with SOS4WIN, the first thing to check is the configuration of archiving. If you have all your archives set to go off at the same time, or they are not sufficiently spaced apart in time, this could potentially cause an application hang. Try to configure your archiving so that each archive has time to finish its data copy before the next one starts. SDR does not use Scheduled Tasks. It runs a process in the background (sosstart.exe) that uses no processing time. If you have turned on SDR, and wish to turn it off, you can 99
  • select Stop SOS Daily Restart from the SDR submenu. This will kill the sosstart.exe process. In order for SDR to work correctly you must go into Options/Settings/General and check the box that says: “Start Synchronizing When SOS4WIN Starts.” Auto Failover Feature This feature is also available from the Tools Menu. You may select this feature and it will ask you which server you want auto failover activated for. That server will be monitored via a TCP ping heartbeat and if it fails to respond at any time in the future, fail over will be automatically initiated. Use this feature with caution. If you forget its on and you restart the main server for maintenance, or for power loss or any other reason, the backup server will take its identity. You would then have a situation where new data is going to the backup server without anyone really being aware of it. For this reason we recommend that you use manual failover GhostBuster From the Tools Menu you will find the GhostBuster program. This is a drive imaging program similar to Norton Ghost, only better.  The GhostBuster Server gives you centralized control over your drive images. You can receive images from PCs, Transmit images to Pcs, and mount images and access individual files from the mounted image. GhostBuster has two clients – a Windows client which can be installed on any PC. The install program for the client is in c:rsync and it is called: GhostBusterClientSetup.exe. The Windows client has the advantage of letting you schedule drive imaging at night. The other client is a CD bootable client. You may download the iso image from here: www.sosstandbyserver.com/download/GBSOSPERM.iso The CD bootable client is always used to rebuild a PC from a previously created image file. GhostBuster allows you to rebuild any PC on your network from bare metal. Simply boot the PC from the CD, set it to receive an image from the menu, select the correct image from the GhostBuster Server console and the image will stream across the network and rebuild the drive. 100
  • There is no per-seat licensing which means that if you own SOS Standby Server you can create drive images of all the servers and workstations on your local area network – for no extra fee! You can also clone one machine to another directly through the network. Miscellaneous Information & FAQ What About Small Business Server? Small Business Server (SBS) – There are special considerations for SBS. You can only have one SBS server on a network. You CAN have a Backup Domain Controller (BDC) on an SBS network, however the BDC cannot be an SBS Server. It can be a 2000 Server. If you are going to be wanting a failover setup for Exchange Server, then you don’t need to worry about a BDC, because for the Exchange Server setup you will be cloning the main server (over the network with our software) to the backup server. Consequently the SOS Backup Server will have active directory on it (by virtue of cloning the OS), and it will not interfere with the main SBS server because it will be cloaked inside a virtual network, or if you don’t use a VM, the SOS Server will be brought up in “Safe Mode With Networking.” More about this in the section under Exchange Server Failover. What this means for SBS users is…if the main server is SBS you have two options: 1. Install 2000, 2003, or 2008 Server for the SOS backup server. You would do this if you do not care about failover for Exchange Server. 2. Clone the SBS Server to the backup server. You do this if you want failover for Exchange Server. The recommended procedure is to clone the SBS server into a virtual machine. For More information on domain controllers in an SBS environment go here: http://support.microsoft.com/kb/q200866/ 101
  • What about Domains & Active Directory? SOS works with all of the above. SOS does not replicate Active Directory because Microsoft already has a solution for that, which is simply to have a second (or backup) domain controller on the network A typical setup would be to configure the SOS standby backup machine as a second domain controller, so that it will be able to authenticate users if the main domain controller fails. However, if you have other domain controllers on the network (besides the main one) then it isn’t necessary to make the backup server a domain controller. If you configure to use a virtual machine (more on that later) then you will have effectively replicated the active directory to the backup server when you cloned the main server into a virtual machine. Update Note: The SOS Software does have the capability of backing up the Active Directory. You simply don’t want to mirror active directory or any part of the OS to the standby server for the simple reason that most server failures are due to OS corruption. You do not want to mirror OS corruption to the backup server and defeat its ability to take over in an emergency. Can I Use XP as the Host on the Standby Server? Yes you can. 64-bit XP would be the best choice if you use XP and have 64-bit hardware. If you use XP and have a large network, watch for this error in the Event Viewer. “TCP/IP has reached the security limit imposed on the number of concurrent TCP connect attempts" If you see that go here and implement the patch: http://www.speedguide.net/read_articles.php?id=1497 This will remove the 10 concurrent connections per second limit on XP. (Vista SP2 and Windows 7 do not have this limitation) Note: This is different from the 10 mapped drive connection limit in XP – that limit won’t affect you if the standby server is running as a virtual machine because the XP host will merely pass the TCP connection without counting it as a network SMB connection. The 10 mapped drive limit cannot legally be changed. Update: Two patch programs are included with SOS. You will find them in c:rsync. Look for tcp10patch.exe or tcpip-patcher.exe. Use one or the other. These might be detected as virus by some antivirus, but they are clean. The alleged reasoning Microsoft gave for making a tcp limit was to slow virus spread on the Internet. Consequently some anti virus programs erroneously report these patches as virus. 102
  • Technical Support We would like to make you aware of our ongoing program to keep your software investment in state-of-the-art condition. We often get feedback from customers concerning enhancements and features they would like to see incorporated into the software. We work diligently to incorporate valuable updates into the software on a regular basis. In 2008 we released an update on an average of one a month. As our customer base grows our software is installed in many varied environments which sometimes bring to light adjustments that need to be made for specialized situations. When you have an annual support contract you will receive all these updates and patches that are released throughout the year for free, along with free phone and email technical support and a reduced labor rate for any on-site or remote hands-on support from Swarbrick Software. Most of our clients purchase support. We believe it is a wise choice. SOS Standby Server is an investment into your disaster recovery plan. Adding annual support will keep that investment up-to-date and and insure it is configured for peak efficiency. Annual support is $800.00 per year. You can give us a call and we'll get you signed up and you can begin receiving our regular program updates. Be sure to view the tutorial for additional instruction. You will find it in the SOS4WIN application: Help/Tutorial. You may email or call us for assistance. We are happy and eager to help potential customers as they setup the trial version of SOS Standby Server. Technical Support…  Free during your two week trial. Support Packages are available at time of purchase. Annual Support provides…  Free email and telephone support on weekdays 9-5 Arizona time  Updates and patches released throughout the year  A reduced labor rate for on-site or remote-in hands-on support. Annual Support is currently priced at $800.00 annually. Questions? Call Us – We Will Be Glad To Assist! Swarbrick Software – 480-430-7780 Email: sales@sosstandbyserver.com Phone: 480-430-7780 103