Section 14.3. Backing Up with Samba

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.

The following pages presuppose at least some familiarity with Samba basics. If you know little about Samba, you should read Part II or at least Chapter 3 and Chapter 4.

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. Creating a backup share

Broadly speaking, you can design a backup share in any of three ways:

  • The share may point directly to the backup device. This approach works only with removable disk or removable hard disk media; you can't point a Samba share directly at an optical disc or tape device. Typically, users then copy their files, either raw or in a compressed carrier archive, to the backup device. The share often includes mechanisms to automatically mount and unmount the backup device, as described shortly.

  • The share points to a holding area in which users copy their files. When the connection is terminated, Samba runs a script that backs up the share using tar, cpio, cdrecord, or other Linux backup tools.

  • The share accepts a prepared carrier archive from the backup client and copies it to a backup medium. This approach handles any metadata the client's backup tools can handle, so Samba's metadata limitations aren't an issue.

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.

One problem with this approach is that Windows systems frequently don't terminate their connections to the server in a timely manner. Thus, the postexec command may not execute until several minutes, or even hours, after activity ceases. Logging out of the Windows session usually terminates it on Windows NT/200x/XP clients, but Windows 9x/Me clients may need to be rebooted. Another approach is to use the global Samba deadtime parameter, which tells Samba how many minutes of inactivity to accept before disconnecting a client. For instance, deadtime = 5 ensures that inactive connections are terminated in five minutes.

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.

If you want to create a very complex print command, try writing a script to do the job and then call the script. This enables you to perform arbitrarily complex actions, while keeping your smb.conf file's share definitions readable. 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 or for a couple of sources) to do the job:


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.

You can enter commands to back up a Windows system into a Windows batch file. Thereafter, running that batch file backs up the client. To make the process even more user-friendly, you can create a desktop object that points to the batch file. Call it Backup or something similar, and users should have no trouble double-clicking it to back up their computers.

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.

Because SMB/CIFS provides limited support for Linux file metadata, server-initiated SMB/CIFS backups of Linux systems are unlikely to work well, except perhaps for partial backups of user data files, particularly on a Samba server. For this reason, this chapter assumes that such backups use Windows backup clients. 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:

  1. Open the Windows Control Panel.

  2. Double-click the Network Connections icon. This displays a window of the same name. (This icon is called Network and Dial-Up Connections in Windows 200x.)

  3. In the new window, right-click the Local Area Connection icon. This produces a pop-up menu; select Properties in this menu. The result is the Local Area Connection Properties dialog box shown in Figure 14-1.

  4. If the protocol list includes an item called File and Printer Sharing for Microsoft Networks, skip ahead to Step #8.

  5. Click the Install button to bring up a dialog box called Select Network Component Type.

  6. Pick the Service item and click Add in the Select Network Component Type dialog box. This should produce the Select Network Service dialog box.

  7. In the Select Network Service dialog box, pick the File and Printer Sharing for Microsoft Networks item, and then click OK. This action will install SMB/CIFS server support on the computer.

  8. In the Local Area Connection Properties dialog box, verify that the File and Printer Sharing for Microsoft Networks item is checked. Click OK in this dialog box to dismiss it.

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.

  1. Open the My Computer folder on the desktop.

  2. Locate the icon for the drive you want to back up, and right-click it to produce a context menu. Select the Sharing and Security item from this menu. (This item may be called Sharing or something else on some versions of Windows.) This action brings up a Properties dialog box with a Sharing tab selected.

  3. In Windows XP, the Sharing tab displays a warning that sharing an entire drive can be a security risk. Click this notice to view the real configuration tab, as shown in Figure 14-2.

  4. Check the "Share this folder on the network" button and enter a name for the share in the "Share name" field. This interface is somewhat different in Windows 200x and Windows 9x/Me. In Windows 200x, you must click the New Share button to enter a share name.

  5. Windows XP allows you to enable or disable write access to the share via the "Allow network users to change my files" button. Windows 9x/Me provides two fields for passwords for read-only and read/write access. A backup share can ordinarily be read-only, although you will have to enable read/write access when you want to restore data.

  6. To start sharing the drive, click OK.

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.

Windows XP Home, which ships on many new computers, provides no password to protect its shares. This configuration makes Windows XP Home a very risky version of Windows to back up using server-initiated backups. If possible, upgrade such computers to Windows XP Professional or Windows 200x to obtain password-based share protections. If this isn't possible, you should at least use a strong firewall to limit access to TCP ports 139 and 445, so that only the backup server and other authorized systems can access the SMB/CIFS file servers on Windows XP Home systems.

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

-s server

You pass the name of the file server (that is, the backup client) with this option.

-x share

You must tell smbclient what share to back up with this option. If you omit it, the program looks for a share called BACKUP.


You can have smbtar provide more verbose information about its actions with this option.

-u username

When connecting with Windows NT/200x/XP servers, smbtar must pass a username to the file server with this parameter.

-p password

Unless the backup share requires no password (a risky configuration), you must deliver one with the -p parameter.


Microsoft filesystems provide an archive bit, which is cleared when files have been backed up and set when they're modified. This can be helpful in performing incremental backups. If you use this option, smbtar clears the archive bit when backing up files.


This option performs an incremental backup by backing up only those files on which the archive bit is set.

-N filename

This option implements a different type of incremental backup system, in which smbtar backs up only files that are newer than the specified filename, which is ordinarily a backup log file from the previous backup.

-t tape

You should pass a filename to smbtar with this option. The filename can be a tape device, such as /dev/st0, or a regular file.


By default, smbtar backs up files from the remote share. This option reverses the process and causes the program to restore files.

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:

Client-initiated removable disk backups

When using removable disks as if they were ordinary file shares, files can be restored by inserting the original backup medium and using drag-and-drop operations to restore files. This practice requires no special extra configuration on the client or the server, except for full restores (as described shortly).

Client-initiated two-stage backups

When the backup server processes data in some way, such as bundling data into a tarball and storing it on tape, a restore operation can be tricky. You may need to extract the data to a special data-restore share on the backup server and then copy it to the client. Alternatively, you may be able to configure the backup client as for a server-initiated backup and use smbtar or similar tools to perform the restore.

Server-initiated backups

In a server-initiated backup scenario, restores can be done very much like the initial backups, but you must specify the restore option (-r) to smbtar to do the work. You must also ensure that the backup client's file server accepts full read/write access to the share, at least when the restore operation is in progress. (If you like, you can disable read/write access once the restore is done.)

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.

When restoring a Windows system to a FAT disk, you can use a Linux emergency disk if your backup archive can be read by Linux. This usually works well, although there may be some minor changes to filename case. Also, short filenames are occasionally restored differently by Linux than by Windows, which can sometimes cause problems if configuration files refer to files by their short filenames.

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.

    Linux in a Windows World
    Linux in a Windows World
    ISBN: 0596007582
    EAN: 2147483647
    Year: 2005
    Pages: 152

    Similar book on Amazon © 2008-2017.
    If you may any questions please contact us: