|
Related topics
Knowing how to back up, rebuild, and restore your FirstClass server in case of emergency are three of your most important responsibilities as an administrator.
Why you should always be prepared
Since FirstClass is easy to administer and dependable, emergencies are rare, but should an emergency arise, you must be prepared to deal with it.
Accidents happen. A power failure or a computer malfunction could destroy everything on your FirstClass server. Without a backup, your users could lose important messages and files, and you could be faced with having to reinstall, reconfigure, and recreate your entire FirstClass system.
To avoid this complicated task, we recommend that you back up your system regularly. It’s also wise to back up your server before upgrading your FirstClass software or your computer hardware.
Why should you perform backups?
There are several instances in which you may require recent backups, making it imperative that you backup your system regularly:
• Security
The most common reason to do a backup is to guard against natural disasters, system malfunction, or software bugs. For example, if you have a hard disk crash and you have not backed up your FirstClass server to another medium, all of the information in your system will be lost. This is also true if there is a disaster at your server site. Fires, floods, electrical storms, and accidents can all cause partial or total destruction of your system. Finally, bugs in both application and system software may cause malfunctions that render your system unusable. In all cases, planning ahead and backing up ensures that you will be able to get your system running again as soon as possible.
• Hardware or software upgrades
If you are upgrading software (FirstClass or other system software), changing CPUs, or adding hardware, you should do a complete backup first in case there are any problems during the upgrade.
• Major FirstClass system changes
Before making significant changes to your FirstClass system, such as adding many users or a gateway, or running a large or complex FirstClass scripting script, ensure you backup your system completely and have the backup on hand. If you make an error in the process that is difficult to undo, you can restore your system to what it was before the error and restart the process.
Choosing a backup schedule
Your backup schedule depends on the value of your data, the likelihood that data will be lost, and the difficulty of doing a backup. For example, let’s look at the backup schedule of Husky Planes. Management has decided that they cannot afford to lose more than one day’s worth of FirstClass data. It has set up the following backup process:
• The FirstClass system is backed up to tape every night.
• Backups are retained for two weeks.
• Every Monday morning, the Sunday night backup is sent to an off-site storage facility.
• All other backups produced during the two-week period are stored in a fire-proof safe on site.
Choosing a backup medium
We recommend that you store your backup on a different medium from the one containing your FirstClass system (such as a DAT tape). If you store your backup on the same drive as your system, and the drive is damaged, neither the FirstClass system nor the backup will be available.
Backing up your server
Once you have installed and configured your server, you should back up the FCNS and FCServer folders (Windows) or the fcns and FirstClass Server folders (Mac OS X).
If you have approved additional volumes, you should also back up the FirstClass network store or FCNS folder on each of those volumes.
Mirroring only needs to be paused while backing up the mirrored network store and should be resumed when the backup is complete.
 WarningNever back up an active server. If you are backing up the server, shut the server down first.
You should schedule regular backups to ensure that you do not lose data due to hardware malfunctions or other problems.
Backing up your network store
When you back up your network store, you make a copy of all the FirstClass data that it contains. This includes messages, the Directory, and the system configuration.
You should set a regular backup schedule and store your backup in a safe place (ideally off-site). You can use any third-party backup utility to back up your FirstClass server.
Make sure you back up the following folders:
• the folder containing the FirstClass network store on the master volume (the volume on which you installed the FirstClass server)
• the folder containing the FirstClass network store on any other approved volumes
• any additional files or folders you may have modified, such as the Inetsvcs.fc file and the CONFIG or CGI-BIN folders.
WarningBack up all your volumes at the same time. If you don't, some of them might be inconsistent and therefore unusable when you restore them.
WarningNever back up an active network store. Back up a paused mirror volume, or shut down the server before performing the backup.
Automated backup
You can automate the backup process using a combination of the mirroring feature, backup software, scripting software, and the appropriate commands based on your operating system and whether you are running the server as a Windows service.
Automated backup on Windows
You can use the FCUtil utility to automate backups whether you are running as a Windows service or not. The commands needed are FCUTIL PAUSE and FCUTIL CONTINUE.
The FCUtil utility is installed in the same folder as the server executable. FCUtil supports many commands, allowing you to automate a variety of tasks. You can get a complete list of commands and syntax by opening a command prompt, changing the path to the path of your executable folder, and entering "FCUTIL".
Automated backup on Mac OS X
You can use the fcsctl utility to automate backups. The commands needed are "fcsctl pause" and "fcsctl continue".
To issue these commands, open a Terminal shell and ensure you are working in the FirstClass server directory.
Snapshot Hold & Release
The snapshot hold and release feature is designed to hold the FirstClass server in a consistent state, take a snapshot of the network store, and release the server back to normal operating mode. Once the hold has been initiated, the server will not respond to any operations except the corresponding snapshot release request until the hold has been released manually or the allotted time
has expired.
Many FirstClass servers use external disk devices for storage of the FirstClass content. Some of these devices, such as NetApp Filers, offer what is referred to as a snapshot facility. Other backup solutions, such as those from Compaq or EMC, offer similar features to provide very fast backups of large amounts of data. In some cases this capability is known as a "split mirror", although that form can take slightly longer to create than the copy-on-write alternative used in NetApp snapshots. There are also software-based "instant backup" solutions, such as BackupExec's "Advanced Open File Option" (see this PDF).
In FirstClass terms, a snapshot is any mechanism (typically provided by a network file server) that enables near-instant flagging of the current state of a file system for later retrieval. This does not need to correspond directly to the snapshot services provided by a NetApp, however it is not suitable for use with a traditional backup due to the time required for the backup copy process. The only FirstClass requirement is that this snapshot process take less than a minute (the default is 60 seconds). The hold operation must be quick because the server process is effectively blocked during the snapshot hold operation, and all requests are deferred until the snapshot release. This permits the snapshot hold to be requested, the snapshot to quickly be taken, and the snapshot release to be requested, allowing the server to
function normally while the backup process begins in parallel. This allows you to do an online backup of your FirstClass server without having to worry about open files or mirroring.
You can invoke the hold and release feature in one of two ways: through the server console menu or through FirstClass scripting.
Server console menu method
This method uses the server console menu (Storage > Snapshot Hold). When you choose this, you are requesting a snapshot hold and the snapshot backup is taken. A few seconds later you request the snapshot release (Storage > Snapshot Release). The server console below shows what happens:
 If the release had not been requested, the server would have automatically resumed normal operations 60 seconds after the hold request was made.
FirstClass scripting method
The second method uses the new FirstClass scripting commands, HOLD and RELEASE, through the FirstClass Provisioning Protocol (FPP).
To request a HOLD, use this syntax:
HOLD OptionalHoldTime
where OptionalHoldTime is the total amount of time, in seconds, until the server will release itself. If not specified, the default is used.
To request a release, use this syntax:
RELEASE
The following result shows both a default (60 seconds) hold request, as well as a timed hold (30 seconds):
 The server console logs these FPP requests.
 |
