لطفا منتظر باشید ...
Using SMB/CIFS
The preceding section, "
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
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
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
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.
you must share all the hard disks you want to be backed up. You can do
so by following these steps:
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
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 //
border=0> WORK/CDRIVE /mnt/backup -o \ username=fred,password= password
The equivalent command using smbmount
is: # smbmount //WORK/CDRIVE /
border=0> mnt/backup -o \ username=fred,password= password
WARNING
align=left border=0> 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
align=left border=0> 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
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 "
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
align=left border=0> 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.
two examples of such shares that back up data to CD-Rs. A variant on the share
shown in the "
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
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 # $1 = Home directory of job submitter # $2 = Filename of zip file # $3 = Username of job submitter # $4 = Path to zip file mkdir -p $1/backup/samba cd $1/backup/samba unzip $4/$2 tar cvpf /dev/st0 ./ > $1/tar.out mail -s "Backup finished" $3 < $1/tar.out rm $1/tar.out rm -r $1/backup/samba
WARNING
align=left border=0> 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
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
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
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.
