14.3. Backing Up with Samba
One of the conceptually simplest network backup tools is Samba, the network file and printer sharing program described in Part II. Using Samba enables you to back up Windows computers using either client- or server-initiated backup procedures. You can also perform client-initiated backups of Linux and other non-Windows computers using Samba, although server-initiated backups of Linux systems are tedious when done with Samba.
Before proceeding further, you should understand the basic features and uses of Samba backups. These determine the advantages and disadvantages of using Samba as part of the backup picture. This chapter also presents two basic Samba backup scenarios: using a backup share for client-initiated backups and using smbtar for server-initiated backups.
14.3.1. Pluses and Minuses of Samba Backups
Samba is a Linux implementation of the SMB/CIFS protocolthe default file-sharing protocol for Windows. Although Samba is frequently considered a server package, it includes client tools. Thus, Samba can be used as part of either a client-initiated (using Samba server tools) or a server-initiated (using Samba client tools) network backup design.
SMB/CIFS supports common Windows filesystem metadata, but it provides limited support for Unix-style ownership, permissions, and other metadata. Thus, SMB/CIFS can be a good way to back up files from Windows systems while preserving metadata, but SMB/CIFS is a poor way to back up Linux or Unix systems. If you transfer data in a carrier file, though, such as creating a tarball on a Linux system and then using SMB/CIFS to copy the tarball across the network and onto a backup device, SMB/CIFS provides no inherent problems relating to preservation of file metadata; that information is stored within the tarball. Such a backup approach is best handled in a client-initiated backup procedure, though, which is why Samba and SMB/CIFS make a poor choice for backing up Linux systems using server-initiated backup methods.
Although SMB/CIFS supports Windows filesystem metadata, Linux doesn't. Samba provides ways to map most important Windows filesystem metadata onto Linux filesystem metadata that Windows can't use. Thus, if you use Samba with identical configurations on backup and restore, chances are you won't lose any important filesystem metadata when restoring data. One exception to this rule is certain advanced NTFS features, such as multiple data streams and (depending on your Samba server's options) support for ownership and ACLs. Thus, you may lose some metadata when backing up a Windows system that uses NTFS in a server-initiated backup or even in some types of client-initiated backup. However, client-initiated backups that use Windows-specific backup software can preserve these metadata.
Another problem with SMB/CIFS backups is that restoring data to the backup client can be tricky, particularly in the case of a complete restore. This topic is covered in more detail later, in the section Section 14.3.4.
On the plus side, support for SMB/CIFS is free in both Windows and Linux. Thus, implementing a Samba-based backup solution can be inexpensive, particularly if you're willing to invest some time in creating appropriate backup scripts. In fact, Samba ships with a tool that's specifically designed with backup in mind: smbtar, which is described shortly.
Because of Samba's support for FAT-style metadata, Samba can be a good way to back up all the data from systems that continue to use FAT. Even some Windows NT/200x/XP systems use FAT, and many of those that use NTFS don't rely heavily on NTFS-specific metadata. Thus, you may be able to back up such systems, or at least their user data, without risking undue loss of file metadata on restore.
14.3.2. Using a Samba Backup Share
The first approach to backup using Samba is to create a special Samba share for the purpose. This Samba share is then accessed from the backup client in a client-initiated backup scenario. Typically, the share accepts files (either directly or in a carrier archive, such as a tarball) and then copies them to a backup device.
22.214.171.124 Creating a backup share
Broadly speaking, you can design a backup share in any of three ways:
From a Samba perspective, the simplest type of backup share is the first: create an ordinary file share that points to your removable disk's mount point. The removable disk can use any common Linux filesystem. You can even use FAT if you think the disk might be read directly by Windows or some other OS in the future, but ironically, using FAT will cause some Windows metadatasuch as archive, hidden, and system bitsto be lost. The tricky part of this type of backup share is mounting and unmounting it. One approach is to use Samba's preexec and postexec configuration parameters. These reside in the smb.conf file's share definition and point to commands that Samba executes when the user connects to or disconnects from, respectively, the share. For instance, a complete backup share might look like this:
[backup] comment = Direct-Access Backup Share directory = /home/samba/backup max connections = 1 read only = No preexec = mount /home/samba/backup postexec = umount /home/samba/backup
The preexec parameter mounts a removable medium to /home/samba/backup. This mount point must be properly defined in /etc/fstab, though. The postexec parameter reverses this process. The max connections = 1 option limits the connections to a single user, which can help avoid problems that might be caused should two users try to use the backup share simultaneously. To the user, the share looks just like any other; it's accessed from Network Neighborhood or My Network Places on a Windows system just like any other share, and it accepts files that are copied there in the Windows file manager or in any other way. Users will presumably insert and remove disks themselves, though, or perhaps ask somebody in physical proximity to the server to do so for them.
A similar approach can be used to back up to tape or to optical media, except that the preexec and postexec options are likely to do more:
preexec = rm -r /home/samba/backup/* postexec = tar cvlC /home/samba/backup --file /dev/st0 ./
These options, used in place of those shown earlier, cause Samba to back up the contents of the backup directory when the user disconnects. (As with a mounted share, Samba may wait a while before doing this, because Windows clients often don't disconnect immediately.) The preexec option tells Samba to delete all the files in the backup directory. This ensures that two consecutive users' backups don't collide.
Perhaps the most flexible type of client-initiated Samba backup, though, uses a printer share, odd as that may sound. The idea is to use a Samba printer share option, print command, to have Samba execute a command that can operate on a single file sent by the client. Typically, this single file is a tarball, Zip file, or other archive file. The print command copies the file to the backup device. For instance, consider this share definition:
[print-bu] comment = Pseudo-Printer Backup Share directory = /var/spool/samba max connections = 1 printable = Yes print command = dd if=%s of=/dev/st0; rm %s
This share uses dd to copy the received file, whatever it is (the %s Samba variable refers to the received print file) to /dev/st0. A more complex command stores the received file on an optical disc using mkisofs and cdrecord, or even uncompresses a tarball and creates a CD-R from its contents. One important point to note about this share is that its print command ends in rm %s. Removing the received print file is vitally important; Samba printer shares don't do so automatically, so if you fail to remove the print file, your backup server's disk will soon overflow with old backup jobs.
126.96.36.199 Using a backup share
The tricky part to using a pseudo-printer backup share comes on the client. You must create a backup archive using local tools and then copy them to the server. For instance, you can use tar for Windows (see http://unxutils.sourceforge.net or http://www.cygwin.com for a couple of sources) to do the job:
C:\> TAR -cvf D:\BACKUP.TAR C:\ C:\> COPY D:\BACKUP.TAR \\BUSERVER\PRINT-BU C:\> DEL D:\BACKUP.TAR
This series of commands, typed at a DOS prompt, backs up the client's C: drive to the PRINT-BU share on the BUSERVER server. This specific set of commands uses D: as a temporary storage area; you may need to change this detail for your own system. Of course, many variants on this approach are possible. For instance, you can use a Zip utility or a dedicated Windows backup tool to create the archive that's copied to the backup server. You can also perform more-or-less the same task using Linux tools, in order to back up a Linux server; however, you'll use the Linux smbclient program to copy a file, rather than the Windows COPY command. If you send a file in tarball form and if Samba dumps it directly to tape, the result will be indistinguishable from creating a backup using a tape drive that's directly connected to the backup client.
All of these client-initiated Samba backup methods do have certain limitations, in addition to those described earlier for client-initiated backups. Most notably, they all require that the Samba server have enough disk space to temporarily hold a complete backup. This disk space must be available in the directory used for the backup share. For removable disk backups, this isn't a very special requirement; the disk space needed must reside on the backup medium itself. For other methods, though, the server must be able to temporarily hold the entire archive before copying it to an external medium. If your backup plan involves manipulating files, such as storing a set of backup files on an optical disc, you may need more space for the temporary files you create in this process.
14.3.3. Using smbtar for Backups
The smbtar program is a script that comes with Samba. It combines the Samba smbclient program and the standard tar utility to read files from an SMB/CIFS server and store them in a tarball or on a tape. As such, it can be a good way to perform a server-initiated backup using SMB/CIFS. To do so, you must first configure your backup clients to share files (that is, to be file servers). Once this is done, you can actually employ smbtar to do the backup.
188.8.131.52 Configuring Windows clients to share files
To perform a server-initiated backup via SMB/CIFS, you must configure the backup client as a file server. On Windows systems, this task requires installing and activating the SMB/CIFS software, although it's not called that in the Windows network tools. A typical procedure, for Windows XP, is as follows:
Figure 14-1. Windows displays the protocols it supports in the Local Area Connection Properties dialog box
Adding SMB/CIFS server support is only part of the job; you must also define shares that the backup server will access. To do so, follow these steps.
Figure 14-2. The Properties dialog box for a disk or directory enables sharing via SMB/CIFS
Unfortunately, every major release of Windows has changed these user interfaces slightly. The preceding description is based largely on Windows XP. Windows 9x/Me is different. Most importantly, the Network icon in the Control Panel brings up a Network dialog box that's similar to the Local Area Connection Properties dialog box (see Figure 14-1).
For Windows XP Professional and Windows 200x systems, you use a local username and password to access the share. For improved security, you might want to create a special backup account that provides read access to all the files you want to back up, but that's not used for ordinary local access. Windows 9x/Me systems use share-level security; i.e., a password without a username provides access to the shares. You enter the password when creating the share, as just noted. From the Linux backup server, you can enter a dummy username; it's ignored by the Windows 9x/Me file server.
Some versions of Windows require you to reboot at some point during this procedure, typically after installing the SMB/CIFS server software but before configuring shares.
184.108.40.206 Backing up with smbtar
Once you've configured a Windows system as a backup client (that is, a file server), you can try using smbtar on the backup server to perform backups. This command's basic syntax is:
smbtar [options] [filenames]
The smbtar command accepts quite a few options, but the most important are:
As an example, consider this command:
$ smbtar -s GINGKO -x CDRIVE -u redwood -p Y#iWT7td -t /dev/st0
This command backs up the CDRIVE share on the GINGKO server, using the redwood account and the password Y#iWT7td, and storing the backup on /dev/st0 (a SCSI tape device). You may also add filenames to the end of the smbtar command line. Doing so backs up the specified files or directories without backing up other files.
Server-initiated backups using smbtar can certainly be convenient, particularly when you want to back up an entire network of computers from a central location. Typically, you'll write a script to back up one computer per night on a small network, or perhaps do several each night on a larger network. Of course, you'll need to ensure that the backup clients are turned on at the scheduled backup times. This backup method is also limited in the types of metadata it can handle. Because smbtar doesn't understand some of the more sophisticated NTFS features, such as ownership and multiple data streams, it might not be a suitable tool for performing complete backups of Windows NT/200x/XP systems. Nonetheless, smbtar may be adequate for backing up user datafiles on Windows workstations, and it can even perform full backups of Windows computers that run off of FAT filesystems.
14.3.4. Restoring Data with Samba
Restoring data over the network introduces an extra component in the equation: the backup client must be able to accept the data transfer. Precisely how this happens depends on how you backed up the data:
With some backup methods, you can restore data without using of a network. For instance, if you back up to an optical disc, and if the backup client has an optical reader that can read the backup, you can restore the data locally. In some cases, you can even move the backup drive to the backup client to perform a local restore without involving the network. This is most likely to be helpful when performing full restores.
With the exception of two-stage backups, partial network restores usually aren't much more work than similar restores would be on a local backup. The real trouble occurs when a full restore is necessary. With these, many of the same problems described earlier with reference to full local restores apply (see the section Section 14.2.4). The difference is that instead of having access to local backup software on the emergency system, you must have access to network toolsyour SMB/CIFS client or server software.
Once you've restored data to a Windows system, you may need to take special steps to ensure that it's bootable. For Windows 9x/Me, you can do this from an emergency boot floppy created from the same version of the OS. Boot from the floppy, and use the FDISK program to mark the boot partition as bootable. You should then type SYS C: to restore a boot loader to the partition's boot sector. With Windows NT/200x/XP, boot from an emergency disk or the Windows installation CD, and select the system repair options. These should detect the lack of boot sectors and correct the problem.