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:
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.
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:
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.
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
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:
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.
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:
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
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
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.