-BackupPC isn't perfect (but it is getting better). Here are some
-limitations of BackupPC:
-
-=over 4
-
-=item Non-unix file attributes not backed up
-
-smbclient doesn't extract the WinXX ACLs, so file attributes other than
-the equivalent (as provided by smbclient) unix attributes are not
-backed up.
-
-=item Locked files 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 L<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.
-
-I suspect there is a way of mirroring the outlook.pst file so
-that at least the mirror copy can be backed up. Or perhaps a
-manual copy can be started at login. Does some WinXX expert
-know how to do this?
-
-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 L<http://www.stbernard.com/products/docs/ofm_whitepaperV8.pdf>.
-If anyone tries these programs with BackupPC please tell us whether or
-not they work.
-
-=item Don't expect to reconstruct a complete WinXX drive
-
-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.
-
-=item Maximum Backup File Sizes
-
-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:
-
-=over 4
-
-=item Perl
-
-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.
-
-=item File system
-
-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.
-
-=item Transport
-
-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.
-
-=back
-
-=item Some tape backup systems aren't smart about hard links
-
-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.
-
-=item Incremental backups might included deleted files
-
-To make browsing and restoring backups easier, incremental backups
-are "filled-in" from the last complete backup when the backup is
-browsed or restored.
-
-However, if a file was deleted by a user after the last full backup, that
-file will still appear in the "filled-in" incremental backup. This is not
-really a specific problem with BackupPC, rather it is a general issue
-with the full/incremental backup paradigm. This minor problem could be
-solved by having smbclient list all files when it does the incremental
-backup. Volunteers anyone?
-
-=back
-
-Comments or suggestions on these issues are welcome.