Using SMBCIFS

Using SMB/CIFS

The preceding section, "Using tar," described using the tar utility in conjunction with an rshd server running on the backup server computer or an NFS server running on the backup client computer. You can use other servers to provide connectivity between the computers, though. This section describes one that's of particular interest to networks that host many Windows computers: the Server Message Block (SMB), aka the Common Internet Filesystem (CIFS). As described in Chapter 7, File and Printer Sharing via Samba, SMB/CIFS support comes standard with Windows systems, and the Linux Samba package allows Linux to interact with these systems using their native file- and printer-sharing protocol. This same protocol can be used for backing up Windows systems, or possibly even Linux systems, using either server-initiated or client-initiated methods . Before proceeding, you should read or review Chapter 7 if you're not already familiar with at least the basics of Samba configuration.

Backing Up Windows Clients from Linux

A server-initiated backup using Samba can work very much like a server-initiated backup using NFS. Samba, SMB/CIFS generally , and Windows present certain unique opportunities and challenges, though. Of particular interest are the capabilities of the smbtar program and unique concerns of processing long filenames from a Windows system.

Sharing Files to Back Up

As with a server-initiated backup via NFS, a server-initiated backup via Samba requires that the backup client run a server to share the files that are to be backed up. In most cases, this works best with Windows backup clients. Although you can run Samba on a Linux computer to share Linux filesystems, and could back them up in this way, the resulting backup would be lacking critical information such as file ownership and permissionsor more precisely, that information would not be reliable.

Windows systems ship with the SMB/CIFS server software, but it may not be installed or configured. Details differ from one version of Windows to another, but you can use the Network or Network and Dial-Up Connections item in the Control Panel to add the necessary software component. In Windows 9 x /Me, double-click Network to get the Network dialog box. In Windows NT and 2000, right-click your network icon in Network and Dial-Up Connections and click Properties. The necessary component is called File and Printer Sharing for Microsoft Networks. If this component isn't present, click Add or Install to do so. You should find it classified as a service, as shown in Figure 17.1. You may also need to set the workgroup to which the system belongs. You can do this from the Identification tab of the Network dialog box in Windows 9 x /Me, or from the System object in the Control Panel in Windows 2000.

Figure 17.1. A Windows system needs the File and Printer Sharing for Microsoft Networks component to function as an SMB/CIFS server.

Once you've installed the SMB/CIFS server, you must share all the hard disks you want to be backed up. You can do so by following these steps:

1. In the My Computer window, right-click the drive you want to share for backups and click Sharing from the resulting pop-up menu. (If the Sharing item doesn't appear, chances are the SMB/CIFS server software is not installed.) The result is a Properties dialog box like the one shown in Figure 17.2.

   Figure 17.2. This is the Windows 2000 Sharing dialog box; the options in Windows 9x/Me are somewhat different.

   

2. Click Shared As or Share This Folder to share the drive. You must then enter a share name , which you'll use to mount or otherwise access the share from the Linux backup server. (In Windows 2000, you enter the share name by clicking New Share.)

3. Windows 9 x /Me systems require you to select an Access Type to specify read-only or read-write access, and to enter a password. You can specify read-only access for backup purposes, but if you ever need to restore data, you'll have to change the configuration to allow read-write access (what's called Full in the Windows 9 x /Me dialog box). You can use the Security tab in Windows 2000 to adjust who may access the share.

4. Click OK to enable sharing on the drive.

5. Repeat Steps 1 through 4 for any additional drives you want to back up.

At this point, the drive should be accessible to remote systems. You can test this from the Network Neighborhood browser of another computer, or by using tools like smbclient from Linux. Both of the methods of server-initiated backup described next use such tools.

Using smbtar

Samba ships with a program called smbtar . As you might guess, this is a tool that combines the features of tar with an SMB/CIFS client. In fact, smbtar is really a shell script that calls the regular tar utility and the smbclient tool, combining their features into a single integrated program you can use to back up a Windows system. You can use it to back up a complete Windows share, or just some files on that share. Its basic syntax is as follows :

 smbtar -s  buclient  [-x  service  ] [-u  username  ] [-p  password  ] \ [-d  dir  ] [-t  device  ] [-r] [-v] 

The smbtar man page provides information on a few additional options. The meanings of these options are as follows:

• -s buclient The only required option is the name of the backup client computer. You normally give the NetBIOS name for the computer, which may not be the same as the system's DNS hostname, but depending upon the name resolve order setting in smb.conf , the system might also respond to DNS hostnames.

• -x service You specify the share name, as defined in the earlier Step 2, as service . If you omit this value, the system defaults to a share called backup .

• -u username If you want to connect with a username other than the one you're using to perform the backup, specify it with this option. Note that Windows 9 x /Me doesn't use usernames on its shares unless it's part of a domain rather than a workgroup.

• -p password If your backup share takes a password, you enter it with this parameter. This is a potentially major security hole because it means the password will show up in your shell's history if you type the smbtar command manually, and the password can also be accessed from a process listing (via the ps utility, for instance). If you run smbtar from a script, be sure the script is readable only by root to keep the password from falling into the wrong hands.

• -d dir You can change to a directory within the share by specifying it with this option. You won't use this option to back up a complete partition.

• -t device Use this option to specify the Linux device file associated with your tape drive, or the file to which you want to store the backup data. The default value is the value of the $TAPE environment variable, or tar.out if $TAPE isn't defined.

• -r The default behavior of smbtar is to back up files. The -r option causes the program to restore files instead.

• -v This option activates verbose mode, in which smbtar displays the names of the files it's backing up.

As an example, consider the following command, which backs up a share called CDRIVE on the computer WORK :

 #  smbtar -s WORK -p   password   -x CDRIVE -t /dev/st0 -v  

The result of running this command is some status information, followed by a list of files, followed by a summary of the number of files and bytes backed up. The file created by smbtar is an ordinary tar file, so you can check and read back the tape using ordinary tar if you like.

Using smbmount

Instead of using smbtar , you can use Linux's ability to mount an SMB/CIFS share to back it up. You can mount such a share using either the mount or the smbmount programs. The former is the normal Linux command for mounting; you specify a filesystem type of smbfs , and you provide the Windows system's NetBIOS name, share name, and username as follows:

 #  mount -t smbfs //  WORK/CDRIVE /mnt/backup -o \ username=fred,password=   password  

The equivalent command using smbmount is:

 #  smbmount //WORK/CDRIVE /  mnt/backup -o \ username=fred,password=   password  

WARNING

The smbmount utility changed substantially over the course of the 2.0. x series of Samba. Earlier versions of the tool used a substantially different syntax. The command shown here should work with Samba versions 2.0.5a through 2.2.2, and probably beyond.

If you omit the password, mount and smbmount both prompt for it. This approach can make using these tools superior to smbtar if you want to perform a backup from the command line. You can also mount multiple computers' drives and back them all up with a single call to tar . This can make creating the backups easier, but it may slow restoration of a single system, because upon restoration, you may need to read through the data from other systems.

After you've backed up data from the Windows computers, you should use the umount or smbumount commands to close the connections with the backup clients. Both commands work the same way, just as umount does with local shares. For instance:

 #  umount /mnt/backup  

Special Windows Filename Considerations

Using Linux to back up Windows systems can be a good way to back up such clients, and especially Windows 9 x /Me systems. There are certain filename caveats, though. The most obvious of these is that mount and smbmount both treat filename case differently than does Windows. To understand this, it's necessary to know something of how Windows stores filenames. The File Allocation Table (FAT) filesystem used by Windows 9 x /Me and optionally by Windows NT, 2000, and XP was initially designed to store filenames with only eight characters and a three-character extension, all in uppercase. This is known as an 8.3 filename. To store longer filenames, Windows implements a separate but associated long filename using extra directory entries. These long filenames can store either filenames that are longer than the 8.3 limit, or filenames with mixed case or an otherwise forced all-lowercase or all-uppercase appearance in Windows. (Depending upon how you view the filename, the case of regular 8.3 filenames will be all uppercase or have an initial capital followed by lowercase letters , as in File.txt . You can force a filename to be all uppercase or all lowercase in file selection dialog boxes and the like by using a long filename entry.) The Linux filename problems derive from the fact that Linux has no way of knowing what the 8.3 filenames are when they differ from the long filenames; Linux uses only the long filenames, if they exist at all.

In contrast to Windows, Linux treats 8.3 filenames in directories mounted with mount or smbmount as being all lowercase (for instance, file.txt ). When restored, these files will be restored correctly; however, if a file was created with an explicitly lowercase but 8.3 filename, the restore process will create a file that will appear as an ordinary 8.3 all-uppercase filename in Windows. This isn't normally a serious problem, because Windows treats filenames in a case-insensitive way. Users may notice small changes in filename case as a result, though, which may be confusing.

The smbtar program treats 8.3 filenames as being entirely uppercase, so it doesn't suffer from this problem, but it does suffer from a related one: Consider a file with a name that's encoded as being all uppercase using the long filename extensions, but that is still 8.3 or shorter in length. The Linux smbtar program will think that such a file is a normal 8.3 filename, and so won't restore the long filename extension that marks it as entirely uppercase. Once again, this problem isn't normally serious, but it may be disconcerting to users.

A potentially more serious filename glitch has to do with the creation of 8.3 filenames to match long filenames. Windows does this automatically, and you can see both the short and the long filenames in a Windows DOS prompt window by using the DIR command. Because Linux doesn't know what the short filename is, though, it relies upon Windows to recreate this filename when restoring files. This process normally proceeds smoothly, and the short filename isn't normally very important in any event. There are cases, though, when it is. Specifically, if a program stores the short filename in a configuration file, and if that short filename changes after restoring the file, the program won't be able to find the file. In fact, the Windows Registry stores some filenames in 8.3 form, so this problem can cause those Registry entries to be incorrect. This, in turn , can cause mysterious malfunctions and even system crashes if a critical Registry entry is affected. You can take some steps to reduce the risk of such problems, though:

• Use short directory names Instead of using long directory names, use short ones. For instance, many Windows programs place themselves in the Program Files directory. If you instead use a directory called APPS , there's no chance that the short filename will be changed upon restoration. Similar changes to the names of subdirectories in which programs place themselves can go a long way towards solving this problem. Chances are data filenames don't need to be short, because Registry entries and the like aren't likely to refer to data files.

• Use long filenames in configuration files If you're given the chance to enter a filename or directory name in a configuration file, use the long filename if it differs from the 8.3 name. For instance, if you want to add a directory to the PATH in AUTOEXEC.BAT , use the long filename. This action ensures that changes to the 8.3 filename won't affect functionality.

• Create long filenames that are unique in their first six characters Windows creates 8.3 filenames by using the first six characters and then appending a tilde ( ~ ) and a number, which is assigned in sequence starting with 1 . For instance, longfilename.txt might have a matched 8.3 filename of LONGFI~1.TXT . If all the long filenames in a directory are unique in their first six characters, they'll all have ~1 as their seventh and eighth characters, and this won't change after restoration.

In the end, the risk of filename-related problems caused by backing up a Windows system from Linux is small, particularly if you take adequate precautions . It's not nonexistent, though, so you may want to have a backup made from a Windows utility, at least for an initial installation.

NOTE

The New Technology Filesystem (NTFS) used by Windows NT, 2000, and XP also stores both 8.3 and long filenames, but it's less dependent upon its 8.3 filenames. Thus, the potential for problems caused by such changes is smaller if you use NTFS than if you use FAT.

Backup Shares

Another approach to using Samba for backups is to create a backup share. This is a Samba share that's linked to a backup device. There are several ways you can go about creating a backup share. Depending upon the approach, you may even be able to use such a system to back up Linux computers. All of these approaches qualify as client-initiated backups.

What Is a Backup Share?

There are two common approaches for creating a backup share using Samba:

• Direct backups You can create a share that's tied to the mount point for a removable media device, like a Zip or Jaz drive. When the medium is mounted, you can access it from a backup client system just as you would any other share. If you run an archiving program, or even just drag-and-drop files, you can back up those files to the removable medium.

• Processed backups You can create a share that uses scripting, as described in Chapter 7's "Samba Scripting Features" section, to copy a file sent by the client to a backup medium. The script might dump the file more-or-less raw to the backup device, or process it in some way. In fact, the "Example: CD Burning" section of Chapter 7 describes precisely such a setup, using a CD-R as the backup medium.

The direct backup approach is quite limited in the size of backups it can handle because most removable-media devices are limited in this respect. Only removable hard disks could handle a backup from a client with a large disk. The processed backup approach is potentially less limiting, but if you must back up clients with large disks, your backup server will need a large disk that's mostly empty to handle the data the client sends, because the server will have to temporarily store the data on its own disk.

Creating a Backup Share

Backup shares can be created like many other types of Samba shares. In the case of a direct backup, the share definition can look much like an ordinary file share. One exception is that you might want to use Samba's scripting features to automatically mount a device when it's first accessed and unmount it when the user has finished the backup. Another feature you might want to use is max connections , which limits the number of users who may access a share at any one time. For instance, the following share definition allows remote users to back up files to Zip disks mounted at /mnt/zip :

 [zip]         comment = Zip Backups         path = /mnt/zip         read only = No         max connections = 1         preexec = /bin/mount /mnt/zip         postexec = /bin/umount /mnt/zip 

NOTE

Because some SMB/CIFS clients, including Windows systems, don't explicitly unmount a share in normal operation, you may want to use the deadtime global parameter to force a disconnection after some period of inactivity. For a backup medium, deadtime = 5 might be reasonable, forcing a disconnect after five minutes of inactivity.

A backup share such as this one is best used to back up limited amounts of data or very small clients. You might use it in a small network to provide access to a removable-media drive from all systems, allowing users to back up their data files to Zip disks or the like.

You can use any filesystem supported by Linux on the removable media, but if the disks must be read by other systems, you should take that fact into consideration. For instance, if your users will take removable disks home and read them on Windows systems, you should use FAT; but if the disks will be used only on the backup server or other Linux systems, you can use FAT, ext2fs, or any other filesystem that Linux supports.

Some media, such as CD-Rs and tapes, aren't easily shared directly. To use such media for backups, you must create a share that actively copies data to the backup medium. Chapter 7's "Example: CD Burning" section presented two examples of such shares that back up data to CD-Rs. A variant on the share shown in the "Burning a CD via a Pseudo-Printer" section is as follows:

 [backup]     path = /var/spool/samba     printable = Yes     print command = /usr/local/bin/samba-backup %H %s %U \                     /var/spool/samba; rm %s 

This share defines a pseudo-printer, which accepts zip files from the backup client. The share uses the /usr/local/bin/samba-backup script, shown in Listing 17.1, to extract the contents of the zip file and copy it to a tape using tar . The result is a backup tape similar to what might be created with smbtar . Alternatively, you could modify the script or the print command parameter to dump the zip file directly to tape, thus preserving features such as the hidden and system bits that would be lost by extracting the files on a Linux system.

Listing 17.1 A script supporting a pseudo-printer backup share

 #!/bin/sh #  = Home directory of job submitter #  = Filename of zip file #  = Username of job submitter #  = Path to zip file mkdir -p /backup/samba cd /backup/samba unzip / tar cvpf /dev/st0 ./ > /tar.out mail -s "Backup finished"  < /tar.out rm /tar.out rm -r /backup/samba 

WARNING

The approach described here requires that the backup device file be accessible to all users. There are ways around this requirement, though. For instance, you could use the root account for all connections. An intermediate approach is to use the force user parameter in the smb.conf share definition to set the effective user ID that submits the "print" command. You could set this user to root or, better yet, create a special group with full read-write access to the tape device and use the force group parameter to grant this share access to the device.

This approach can easily be adapted to process files other than zip files. For instance, if the system accepts a tar file, it could be copied directly to tape without the extraction process that occupies much of Listing 17.1. Such an approach would be faster, but might be less convenient for Windows clients because tar is less common on Windows than it is on Linux.

Using a Backup Share

As described in Chapter 7, a pseudo-printer backup system like this one requires that you create the archive file locally and send it to the backup server without using a printer driver. You can create a Windows batch file to do the entire backup by double-clicking a single desktop icon. When the job is done, the script in Listing 17.1 mails a report to the user's Linux account showing the output of tar , and hence a list of the files that were backed up.

Because this approach, at least as implemented by a pseudo-printer, requires the transmission of an archive file of some sort , you can use this method to back up Linux systems without loss of important UNIX-style filesystem data, so long as the archive format supports that filesystem data. If you set up a pseudo-printer to accept a tar file, for instance, you can use this method to back up Linux clients. This approach has the advantage of potentially better security on the backup server than is available with the rshd approach described earlier. With Samba, you can restrict access based on IP address, just as with rshd , but you can also require a password. A Samba printer share is also less powerful than is the access granted by rshd . On the downside, this method requires that the backup server have a great deal of free disk space. It may also take longer to process backup jobs, and there's the potential for conflicts if two users submit backup jobs in quick succession.