Backing up Windows® Clients on UNIX

Tim Jones

At one point in ancient computer history, UNIX sys admins had very little (if any) responsibility for backups of data on desktop computers. Either the data was not protected, users were instructed to save important data onto a server that WAS backed up, or they were given some tool that would back up at the local system. As we all know, the data was either backed up once in a blue moon or not at all. However, as more interconnectivity occurs between the data center and the desktop, sys admins are now responsible for providing backup and recovery services for these new customers. In this article, we will examine the tools, the steps, and some of the pitfalls in providing these services.

Since all variants of the UNIX operating system include tools and utilities to facilitate backup, UNIX sys admins are much more prepared to provide backup services than other IT administrators. With other operating systems, backup utilities are add-ons that require specific knowledge of the package being used to provide useful backup strategies. UNIX, however, provides a rich set of tools with the "UNIX Look and Feel" to provide scriptable methods for backing up anything from a single file to a full enterprise network.

The availability of these tools, along with the new set of connectivity options that are a part of the average desktop environment (Microsoft's options in particular) make it possible for the UNIX sysadmin to provide backup services that are predictable and reliable for desktop system user data.

Of the tools included in UNIX systems, the more commonly used include tar, cpio, dump, and backup. Each of these provides basic file-by-file backup and restore capabilities, but may be limited in their abilities to ensure the reliability of the backup. They may also be limited in their ability to properly deal with problems that can occur with the backup media at the time a restore is required. To enhance or reduce the shortcomings of these tools, additional vendor utilities and freely available tools, like afio, amanda, fbackup, xfsdump, and pax, are joined by a wide range of commercial backup and recovery options, including EST's BRU 2000, Legato Networker, NetBackup from Veritas, Cheyenne's ArcServe Open, Budtool from Intelliguard, CTAR from UniTrends, and many others. These third-party tools are all designed to improve the reliability or management options of backup and recovery in the UNIX system environments. Choosing the proper tool, whether free or commercial, can ensure that recoveries are successful and easy to perform.

In addition to the variety of software solutions available to UNIX sys admins, a wide range of backup devices can also be used. These include tape drives (4mm, AIT, DLT, QIC, 8mm, and others) and removable disk drives (Iomega Zip and Jaz, SyQuest SyJet, ezflyer, SparQ, and other products). Removable disk manufacturers have attempted to position their drives as useful for backup. However, these devices, because of the relatively high media costs ($/GB) and low capacity (less than 2GB), usually end up as another mountable filesystem instead of playing the role of backup device. Tape drives, on the other hand, will almost exclusively be used as backup devices, since they are not mountable as normal UNIX filesystems. Additionally, many newer tape technologies provide attractive media prices.

Desktops Challenge

In the average UNIX-centric IS shop, the UNIX servers are backed up on a regular basis. Desktops, however, are more of a challenge, and are therefore usually excluded or backed up on a hit or miss schedule. This neglect is generally related to two issues: the apparent incompatibility of the Microsoft and UNIX environments, and the feeling that the data stored on the desktop systems is less important than the UNIX data.

However as more Windows-based desktop applications provide tasks that are important to the daily operations of an organization, answers must be found to provide proper backup of these desktop systems. There are a few obvious options, including providing local backup devices for the desktop users or requiring important data to be stored on a server that is included in the normal backup operations. Providing local backup devices is a duplication of service and can become expensive in both hardware and support costs. Providing a server to support the Microsoft desktops can be just as expensive, because it can mean installing a new system such as Windows NT or Novell's NetWare to provide file server services.

During the past few years, however, a team of Internet-based developers led by Andrew Tridgell has created Samba. Samba is a suite of tools that allows a UNIX server to play the role of a Windows NT server, looking like just another Windows system to the Microsoft desktop systems on the network. This allows Windows desktops to access defined filesystems on the UNIX servers as if they were local drives. Therefore, any files saved to these Samba filesystems can be easily included in that server's normal backup schedule.

Samba uses the SMB (Server Message Block) protocol and provides most of the services that a Windows NT or LAN Manager server can provide. In fact, in addition to the file server aspects that Samba provides, it can also allow your Windows users access to UNIX-based printers. Samba is freely available from http://samba.anu.edu.au/samba/ or one of the international mirror sites listed there. For a description of Samba, refer to the sidebar entitled "What is Samba?".

In addition to the Samba suite's ability to share its volumes and printers to SMB clients, the suite includes a tool called smbmount that allows a UNIX system to mount a Microsoft client's shared volumes as if they were NFS volumes. Thus, it is possible to process the Windows desktops just as you would process other UNIX-based systems mounted using NFS.

But, it can't be that simple, can it? Actually, there is one issue that arises when trying to back up Windows desktops using either mechanism provided by Samba: The Windows System Registry. Shared volume access, even at the root level of the C: drive, does not allow us to read the various files associated with the Registry. Even when using a commercial application that provides client support specific to the Windows desktops, the Registry is often overlooked or processed improperly. This does not mean, however, that you can't back up the contents of the Registry. With a tool that Microsoft provides, called REGEDIT.EXE, each user's desktop system can export its Registry to a text file that can be backed up, thereby ensuring that the information is processed properly. In the event that the Registry is small, it is possible to store it on a floppy diskette. However, once a Windows system has been built up to include a full set of user applications, the resulting text file will exceed the capacity of a standard floppy drive. So, including this file in the backup performed on the server will provide a copy that can be recovered in the event that the live Registry becomes corrupted.

Making Things Work

The first step is to decide whether you want users to store important data on a filesystem on the UNIX server or have the server smbmount the desktops and back them up as separate systems.

Serving Files

Positioning the UNIX server as a SMB file server will allow you to provide strict controls on what data is protected. And, to the desktop user, this file storage area will appear as just another drive letter. Figure 1 shows a Samba UNIX-based filesystem as it appears to an NT workstation. Notice the icon in the lower left of the window. The BNC Tee connector indicates (along with the name of the drive) that this is a mounted SMB volume. For purposes of filesystem use, it appears in the NT drive list as the F: drive.

To set this up, I used the Samba configuration in Listing 1 on the system named "Cheops". (All listings for this article can be found at: ftp.mfi.com in /pub/sysadmin.)

These settings allow users on the NT box to access their home directories on the UNIX server. These also set the Netbios system name and workgroup name that the UNIX system will be seen as on the Microsoft systems. The magic entries are the "security" and "read only" entries. Using a security level of SHARE, the Samba server uses the user's login and password from the Windows desktop to provide the user name and password for the UNIX server. This means the information must be the same on both systems. By setting the "read only" entry to "no", the user is able to update and save data on the shared volume. Depending on your security requirements, the security entry offers two additional arguments: USER and SERVER. For further information on these two settings, refer to the smb.conf man page included with the Samba package.

When you use this type of configuration and desktop users are storing important information on the UNIX system, you can perform backups of the data by simply including the user's home directory in your UNIX system backups. No further action needs to be taken to provide backup support.

However, this limits the data that is protected to that which is actually stored on the UNIX server. If there is concern that the desktops require a more thorough backup, then using the UNIX system to mount the desktops' shared volumes is the best method of providing backup services on the UNIX system.

Unfortunately, if you are not using Linux as your server operating system, this is the only method available for providing backup services for desktop systems without use of additional third-party software. For other UNIX platforms, there is a product called "Rumba" from Objective Development (http://www.obdev.at/) that offers a user space version of the Linux smbfs filesystem. Rumba can be downloaded in source form from ftp.obdev.at in the /pub/Products/rumba directory. The latest (and probably last version) is 0.6a. Object Development lists Rumba as currently operating with Linux, FreeBSD, NEXTStep, NetBSD, HP/UX, Solaris 2.x, and IRIX, but indicates that porting to other platforms should be relatively straightforward.

Objective Development also offers a newer CIFS (the new name for SMB) client that is more robust and offers a better option for filesysytem sharing than NFS under UNIX (when combined with Samba as a server). This product is called "Sharity." Although Sharity isn't free, it is an inexpensive option for connecting UNIX systems and Windows desktops. For more information, visit the Objective Development Web site mentioned above.

Backing up Shares on a UNIX Server

Configuring a Microsoft desktop to allow the UNIX system to mount the necessary shared volumes depends upon which Microsoft platform you are running. For Windows NT, you must create an appropriate user and give that user appropriate access to the volumes being backed up. See Figure 2 for an example of setting up a user called "backup".

Notice that this user is not allowed to change the account password. Also, you should assign this new user to the "Backup Operators" group (see Figure 3).

You also need to configure your volume shares to give this new user access. This is done in the volume's Properties dialog (see Figures 4a and 4b). Notice that I've assigned Full Control access to both the backup user and the "Backup Operators" group. This may not meet with your security requirements, however, so select only the highest level of access control that you require to provide backup services for the desktop volumes.

On a Windows 95 system, configuring a shared volume is less complex, but also less secure. As shown in Figure 5, a shared volume offers two access levels. Although you can provide a password for accessing the volume as read only or full access, backup access should only require "Read-Only" access to allow you to properly backup a Windows 95 desktop.

Once a volume has been properly shared, it will show up with the hand icon as seen in Figure 6. If this volume is the system, or boot, volume on the machine that you are sharing, you should ensure that you can process the system Registry. To do this, use the Windows program REGEDIT.EXE and choose File -> Export and save the entire Registry to a text file. This operation is the same under Windows 95/98 and Windows NT (see Figure 7). To check the availability of the share on the backup server, use the smbclient tool. To check a machine named KINGTUT, run smbclient as shown in Listing 2.

Once you've created the volume shares on the desktop systems and checked that the server's smbclient can see them properly, the next step is to mount the shared volumes on the UNIX server. For this example, I'll use a mount point directory named /desktops. We can either choose to mount each volume simultaneously and perform a single backup operation, or, we can use a script to mount each volume in turn and back them up as separate backup sets on a single tape. The script in Listing 3 shows one way of implementing this second strategy. Of course, you could also mount the systems by department or function. This choice should be made based upon your networking strategy and system availability requirements.

Now that our backups have been created and verified successfully, we need to track which systems are on which tape. As part of the messages that are produced by our script, we report which backup set each shared volume is in on the given tape. Therefore, to restore files from the shared volume that was the second backup on the tape, use the mt command with the non-rewinding tape device and space over the first backup set. Next, smbmount the shared volume on its original mount point and perform the restore. Listing 4 shows the steps required.

If this restore involved the restore of the Registry, by simply restoring the proper Registry file and then importing it into REGEDIT.EXE, we can return a system to the state it was in when our backup was performed. Be sure to rewind the tape when you're done and return it to safe storage.

I'm certain that there as many variations on this process as there are readers of this article. I only hope that I've helped you understand some of the methods that can be used to allow UNIX sys admins to provide the backup services that the Microsoft desktops require.

About the Author

Tim Jones is Vice President of Enhanced Software Technologies, Inc. He has been involved with UNIX systems since 1983 and tape and backups since 1986. He was the UNIX product manager for Archive Corp. prior to the Conner Peripherals takeover and is responsible for the development and marketing efforts surrounding EST's BRU 2000 and QuickStart products. He loves Linux almost as much as his Porsche 914.