|
|
|
|
smbclient doesn't extract the WinXX ACLs, so file attributes other than the equivalent (as provided by smbclient) unix attributes are not backed up.
Under WinXX a locked file cannot be read by smbclient. Such files will not be backed up. This includes the WinXX system registry files.
This is especially troublesome for Outlook, which stores all its data in a single large file and keeps it locked whenever it is running. Since many users keep Outlook running all the time their machine is up their Outlook file will not be backed up. Sadly, this file is the most important file to backup. As one workaround, Microsoft has a user-level application that periodically asks the user if they want to make a copy of their outlook.pst file. This copy can then be backed up by BackupPC. See http://office.microsoft.com/downloads/2002/pfbackup.aspx.
Similarly, all of the data for WinXX services like SQL databases, Exchange etc won't be backed up. If these applications support some kind of export or utility to save their data to disk then this can =used to create files that BackupPC can backup.
So far, the best that BackupPC can do is send warning emails to the user saying that their outlook files haven't been backed up in X days. (X is configurable.) The message invites the user to exit Outlook and gives a URL to manually start a backup.
With Windows 2003 and WinXP the Volume Shadow feature (VSS) allows open files to be copied. VSS is the capability that creates volume snapshots for backup purposes See:
http://blogs.msdn.com/adioltean/archive/2005/01/05/346793.aspx
Comment: two users have noted that there are commercial OFM (open file manager) products that are designed to solve this problem, for example from St. Bernard or Columbia Data Products. Apparently Veritas and Legato bundle this product with their commercial products. See for example http://www.stbernard.com/products/docs/ofm_whitepaperV8.pdf. If anyone tries these programs with BackupPC please tell us whether or not they work.
Comment: Bacula (open source backup to disk) has implemented support for VSS, allowing open file backup. The on-going development of the BackupPCd client should eventually include similar VSS support, finally providing an open-file backup solution in BackupPC.
The conclusion from the last few items is that BackupPC is not intended to allow a complete WinXX disk to be re-imaged from the backup. Our approach to system restore in the event of catastrophic failure is to re-image a new disk from a generic master, and then use the BackupPC archive to restore user files.
It is likely that linux/unix backups done using tar (rather than smb) can be used to reconstruct a complete file system, although I haven't tried it.
BackupPC can backup and manage very large file sizes, probably as large as 2^51 bytes (when a double-precision number's mantissa can no longer represent an integer exactly). In practice, several things outside BackupPC limit the maximum individual file size. Any one of the following items will limit the maximum individual file size:
Perl needs to be compiled with uselargefiles defined. Check your installation with:
perl -V | egrep largefiles
Without this, the maximum file size will be 2GB.
The BackupPC pool and data directories must be on a file system that supports large files.
Without this, the maximum file size will be 2GB.
The transport mechanism also limits the maximum individual file size.
GNU tar maximum file size is limited by the tar header format. The tar header uses 11 octal digits to represent the file size, which is 33 bits or 8GB. I vaguely recall (but I haven't recently checked) that GNU tar uses an extra octal digit (replacing a trailing delimiter) if necessary, allowing 64GB files. So tar transport limits the maximum file size to 8GB or perhaps 64GB. It is possible that files >= 8GB don't work; this needs to be looked into.
Smbclient is limited to 4GB file sizes. Moreover, a bug in smbclient (mixing signed and unsigned 32 bit values) causes it to incorrectly do the tar octal conversion for file sizes from 2GB-4GB. BackupPC_tarExtract knows about this bug and can recover the correct file size. So smbclient transport works up to 4GB file sizes.
Rsync running on Cygwin is limited to either 2GB or 4GB file sizes. More testing needs to be done to verify the file size limit for rsync on various platforms.
If you backup the BackupPC pool to tape you need to make sure that the tape backup system is smart about hard links. For example, if you simply try to tar the BackupPC pool to tape you will backup a lot more data than is necessary.
Using the example at the start of the installation section, 65 hosts are backed up with each full backup averaging 3.2GB. Storing one full backup and two incremental backups per laptop is around 240GB of raw data. But because of the pooling of identical files, only 87GB is used (with compression the total is lower). If you run du or tar on the data directory, there will appear to be 240GB of data, plus the size of the pool (around 87GB), or 327GB total.
If your tape backup system is not smart about hard links an alternative is to periodically backup just the last successful backup for each host to tape. Another alternative is to do a low-level dump of the pool file system (ie: /dev/hda1 or similar) using dump(1).
Supporting more efficient tape backup is an area for further development.
An incremental backup with smbclient or tar backs up files based only on the mtime (modification time) of the files. Any files with modification times after 1 hour prior to the last full backup are included in the incremental.
This means that files that are deleted, renamed or extracted from an archive (preserving the original modification time) won't be backed up by an smbclient or tar incremental. Rsync, in contrast, inspects the complete list of files in an incremental and checks all the meta data: present or not, size, mtime, owner, group, permissions, and backs up all files with any changes to their meta data. Therefore, with rsync, incrementals are accurate, since any deleted, renamed or new files are correctly noticed.
To make browsing and restoring backups easier, incremental backups are ``filled-in'' from the last complete backup when the backup is browsed or restored.
This means the incremental view presented by BackupPC might not be accurate for smbclient and tar: deleted files, renamed files or files extracted from archives since the last full backup won't be noticed or displayed.
The solution for SMB is to replace smbclient with FileSys::SmbClient. This will give BackupPC full access to the file attributes on the client.
Comments or suggestions on these issues are welcome.