| BackupPC |
|
|
|
|
||
|
BackupPC |
This documentation describes BackupPC version 1.02, released on 28 Oct 2001.
BackupPC is a high-performance, enterprise-grade system for backing up Linux and WinXX PCs and laptops to a server's disk. BackupPC is highly configurable and easy to install and maintain.
Given the ever decreasing cost of disks and raid systems, it is now practical and cost effective to backup a large number of machines onto a server's local disk or network storage. For some sites, this might be the complete backup solution. For other sites, additional permanent archives could be created by periodically backing up the server to tape.
Features include:
BackupPC uses smbclient and nmblookup from the samba package to actually extract the files from each PC client.
BackupPC ``fills-in'' an incremental dump from the last complete dump so that it looks like a complete dump. This makes browsing and restoring backups easier.
BackupPC saves backups onto disk. Because of pooling you can relatively economically keep several weeks (perhaps months) of old backups. But BackupPC does not provide permanent storage to tape. Other Open Source applications can do this by backing up BackupPC's pool directories to tape.
At some sites the disk-based backup will be adequate, without a secondary tape backup. This system is robust to any single failure: if a client disk fails or loses files, the BackupPC server can be used to restore files. If the server disk fails, BackupPC can be restarted on a fresh file system, and create new backups from the clients. The chance of the server disk failing can be made very small by spending more money on increasingly better RAID systems.
At other sites a secondary tape backup will be required. This tape backup can be done perhaps weekly from the BackupPC pool file system.
One comment: in the US in particular, permanent backups of things like email are becoming strongly discouraged by lawyers because of discovery prior to possible litigation. Using BackupPC without tape backup allows recent file changes or losses to be restored, but without keeping a history more than a month or two old.
http://backuppc.sourceforge.net
This page has links to the current documentation, the SourceForge project page and general information.
http://sourceforge.net/projects/backuppc
This page has links to the current releases of BackupPC.
You are encouraged to subscribe to either the backuppc-announce or backuppc-users mail list on sourceforge.net at either:
http://lists.sourceforge.net/lists/listinfo/backuppc-announce
http://lists.sourceforge.net/lists/listinfo/backuppc-users
The backuppc-announce list is moderated and is used only for important announcements (eg: new versions). It is low traffic. You only need to subscribe to one list: backuppc-users also receives any messages on backuppc-announce.
To post a message to the backuppc-users list, send an email to
backuppc-users@lists.sourceforge.net
Do not send subscription requests to this address!
Two popular open source packages that do tape backup are Amanda (http://www.amanda.org) and afbackup (http://sourceforge.net/projects/afbackup). Amanda can also backup WinXX machines to tape using samba. These packages can be used as backends to BackupPC to backup the BackupPC server data to tape.
BackupPC requires:
When BackupPC starts with an empty pool, all the backup data will be written to pool on disk. After more backups are done, a higher percentage of incoming files will already be in the pool. BackupPC is able to avoid writing to disk new files that are already in the pool (this featured was added in version 1.02; prior to that all incoming files were first written to disk). So over time disk writes will reduce significantly (by perhaps a factor of 10 or more), since eventually 90% or more of incoming backup files are typically in the pool. Disk reads from the pool are still needed to do file compares to verify files are an exact match. So, with a mature pool, if a relatively fast client generates data at say 1MB/sec, and you run 4 simultaneous backups, there will be an average server disk load of about 4MB/sec reads and 0.4MB/sec writes (assuming 90% of the incoming files are in the pool).
See http://www.samba.org for source and binaries. It's pretty easy to fetch and compile samba, and just grab smbclient and nmblookup, without doing the installation. Alternatively, http://www.samba.org has binary distributions for most platforms.
Here's one real example for an environment that is backing up 65 laptops. Each full backup averages 3.2GB. Each incremental backup averages about 0.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. (In fact, since the incremental backups are ``filled-in'' with hard links to look like a complete backup, the server is effectively storing 195 complete backups averaging 3.2GB each, or 624GB in just 87GB of space.)
Here's a rule of thumb. Add up the C drive usage of all the machines you want to backup (210GB in the example above). This is a rough minimum space estimate that should allow a couple of full backups and at least half a dozen incremental backups per machine. Add some margin in case you add more machines or decide to keep more old backups.
Your actual mileage will depend upon the types of applications your users have and how common these applications are between machines.
For example, the Eudora email tool stores each mail folder in a separate file, and attachments are extracted as separate files. So in the sadly common case of a large attachment emailed to many recipients, Eudora will extract the attachment into a new file. When these machines are backed up, only one copy of the file will be stored on the server, even though the file appears in many different full or incremental dumps. In this sense Eudora is a ``friendly'' application from the point of view of backup storage requirements.
An example at the other end of the spectrum is Outlook. Everything (email bodies, attachments, calendar, contact lists) is stored in a single file, which often becomes huge. Any change to this file requires a separate copy of the file to be saved during backup. Outlook is even more troublesome, since it keeps this file locked all the time, so it cannot be read by smbclient whenever Outlook is running. See the Limitations section for more discussion of this problem.
Download the latest version from http://backuppc.sourceforge.net.
After fetching BackupPC-1.02.tar.gz, run these commands as root:
tar zxf BackupPC-1.02.tar.gz
cd BackupPC-1.02
perl configure.pl
You will be prompted for the full paths of various executables, and you will be prompted for the following information:
On this installation, this is __TOPDIR__.
On this installation, this is __INSTALLDIR__.
After running configure.pl, browse through the config file, __INSTALLDIR__/conf/config.pl, and make sure all the default settings are correct. In particular, you will need to set the smb share password, backup policies and check the email message headers and bodies.
BackupPC needs to know the smb share user name and password for each PC. The user name is specified in $Conf{SmbShareUserName}. There are four ways to tell BackupPC the smb share password:
Placement and protection of the smb share password is a possible security risk, so please double-check the file and directory permissions. In a future version there will probably be support for encryption of this password, but a private key will still have to be stored in a protected place. Suggestions are welcome.
The file __TOPDIR__/conf/hosts contains the list of hosts to backup.
Each line in the hosts file contains three fields, separated by white space:
The first non-comment line of the hosts file is special: it contains the names of the columns and should not be edited.
Here's a simple example of a hosts file:
host dhcp user
farside 0 craig
larson 1 gary
The range of DHCP addresses to search is specified in $Conf{DHCPAddressRanges}.
The installation contains an init.d backuppc script that can be copied to /etc/init.d so that BackupPC can auto-start on boot. See init.d/README for further instructions.
BackupPC should be ready to start. If you installed the init.d script, then you should be able to run BackupPC with:
/etc/init.d/BackupPC start
Otherwise, just run
__INSTALLDIR__/bin/BackupPC -d
as user __BACKUPPCUSER__. The -d option tells BackupPC to run as a daemon (ie: it does an additional fork).
Any immediate errors will be printed to stderr and BackupPC will quit. Otherwise, look in __TOPDIR__/log/LOG and verify that BackupPC reports it has started and all is ok.
You should telnet to BackupPC to make sure it is listening. On linux, telnet tries to negotiate various things that BackupPC doesn't understand. The -K option appears to turn this off:
telnet -K ServerHost ServerPort
eg:
telnet -K farside 2359
where $Conf{ServerHost} and $Conf{ServerPort} are set in the configuration file. On Solaris a plain telnet should be fine.
You can request status information and start and stop backups using this interface. This interface is mainly provided for the CGI interface (and some of the BackupPC sub-programs use it too). But right now we just want to make sure BackupPC is happy. Each of these commands should produce some status output:
status info
status jobs
status hosts
The returned values will be some hashes printed with Data::Dumper. The jobs status should initially show just BackupPC_trashClean. The hosts status should produce a list of every host you have listed in __TOPDIR__/conf/hosts.
You can also request that all hosts be queued:
backup all
You can logout with:
quit
Note that this socket interface is not secure: anyone can run this telnet command. The set of commands you can issue is restricted. In future versions there might be an authentication handshake using a shared private key. Comments are welcome.
At this point you should make sure the CGI interface works since it will be much easier to see what is going on. That's our next subject.
The CGI interface script is a powerful and flexible way to see and control what BackupPC is doing. It is written for an Apache server.
The CGI interface should have been installed by the configure.pl script in __CGIDIR__/BackupPC_Admin. BackupPC_Admin should have been installed as setuid to the BackupPC user, in addition to user and group execute permission. You should be very careful about permissions on BackupPC_Admin and directory __CGIDIR__: it is important that normal users cannot directly execute or change BackupPC_Admin, otherwise they can access backup files from any PC. You might need to change the group ownership of BackupPC_Admin to a group that Apache belongs to so that Apache can execute it (don't add ``other'' execute permission!).
BackupPC_Admin requires that users are authenticated by Apache. Specifically, it expects that Apache sets the REMOTE_USER environment variable when it runs. To do this you should create a .htaccess file in the cgi-bin directory that looks like:
AuthGroupFile /etc/httpd/conf/group # <--- change path as needed
AuthUserFile /etc/http/conf/passwd # <--- change path as needed
AuthType basic
AuthName "access"
require valid-user
You will also need ``AllowOverride Indexes AuthConfig'' in the Apache httpd.conf file to enable the .htaccess file. Alternatively, everything can go in the Apache httpd.conf file inside a Location directive. The list of users and password file above can be extracted from the NIS passwd file.
This section will probably grow based on the types of questions on the BackupPC mail list.
Assuming BackupPC can start correctly you should inspect __TOPDIR__/log/LOG for any errors. Assuming backups for a particular host start, you should be able to look in __TOPDIR__/pc/$host/LOG for error messages specific to that host.
The most likely problems will relate to connecting to the smb shares on each host. On each failed backup, a file __TOPDIR__/pc/$host/SmbERR will be created. This is the stderr output from smbclient. The first line will show the full smbclient command that was run. Based on the error messages you should figure out what is wrong. Possible errors on the server side are invalid host, invalid share name, bad username or password. Possible errors on the client side are misconfiguration of the share, username or password.
You should run smbclient manually and verify that you can connect to the host in interactive mode, eg:
smbclient '\\hostName\shareName' -U userName
shareName should match the $Conf{SmbShareName} setting and userName should match the the $Conf{SmbShareUserName} setting.
You will be prompted for the password. You should then see this prompt:
smb: \>
Verify that ``ls'' works and then type ``quit'' to exit.
Secondly, you should also verify that nmblookup correctly returns the netbios name. This is essential for DHCP hosts, and depending upon the setting of $Conf{FixedIPNetBiosNameCheck} might also be required for fixed IP address hosts too. Run this command:
nmblookup -A hostName
Verify that the host name is printed. The output might look like:
received 7 names
DELLLS13 <00> - P <ACTIVE>
DOMAINNAME <00> - <GROUP> P <ACTIVE>
DELLLS13 <20> - P <ACTIVE>
DOMAINNAME <1e> - <GROUP> P <ACTIVE>
DELLLS13 <03> - P <ACTIVE>
DELLLS13$ <03> - P <ACTIVE>
CRAIG <03> - P <ACTIVE>
The first name, converted to lower case, is used for the host name.
Identical files on multiples backups are replaced by hard links. Hardlinks are used so that identical files all refer to the same physical file on the server's disk. Also, hard links maintain reference counts so that BackupPC knows when to deleted unused files from the pool.
The pooling system used by BackupPC is just a chained hash table stored on a (big) file system.
Using the file length and just the first 4096 bytes of the file for the MD5 digest produces some repetitions. One example: with 900,000 unique files in the pool, this hash gives about 7,000 repeated files, and in the worse case 500 files have the same hash. That's not bad: we only have to do a single file compare 99.2% of the time. But in the worse case we have to compare as many as 500 files checking for a match.
With a modest increase in CPU time, if we use the file length and the first 256K of the file we now only have 500 repeated files and in the worse case around 20 files have the same hash. Furthermore, if we instead use the first and last 128K of the file (more specifically, the first and eighth 128K chunks for files larger than 1MB) we get only 300 repeated files and in the worse case around 20 files have the same hash.
Based on this experimentation, this is the hash function used by BackupPC. It is important that you don't change the hash function after files are already in the pool. Otherwise your pool will grow to twice the size until all the old backups (and all the old files with old hashes) eventually expire.
On the other hand, uncompressing is often a factor of ten or so faster than compression. Since most of the time a newly backed up file is not unique (it is likely already in the pool), the pool comparison can be done by comparing the uncompressed pool file to the new file, rather than comparing the compressed new file to the pool. This is how BackupPC will efficiently implement compression. Compression should provide an additional 40% saving in pool size, at the expense of more CPU time (but a lot less CPU time than other backup systems that compress all incoming data).
As of version 1.02 most of the code is in place to support compression, so you should expect it soon.
BackupPC reads the configuration information from __TOPDIR__/conf/config.pl. It then runs and manages all the backup activity. It maintains queues of pending backup requests, user backup requests and administrative commands. Based on the configuration various requests will be executed simultaneously.
As specified by $Conf{WakeupSchedule}, BackupPC wakes up periodically to queue backups on all the PCs. This is a four step process:
The backup is done using samba's smbclient piped into BackupPC_tarExtract, extracting the dump into __TOPDIR__/pc/$host/new. The smbclient output is put into __TOPDIR__/pc/$host/SmbLOG.
As BackupPC_tarExtract extracts the files from smbclient, it checks each file in the backup to see if it is identical to an existing file from any previous backup of any PC. It does this without needed to write the file to disk. If the file matches an existing file, a hardlink is created to the existing file in the pool. If the file does not match any existing files, the file is written to disk and the file name is saved in __TOPDIR__/pc/$host/NewFileList for later processing by BackupPC_link. BackupPC_tarExtract can handle arbitrarily large files and multiple candidate matching files without needing to write the file to disk in the case of a match. This significantly reduces disk writes (and also reads, since the pool file comparison is done disk to memory, rather than disk to disk).
Based on the configuration settings, BackupPC_dump checks each old backup to see if any should be removed. Any expired backups are moved to __TOPDIR__/trash for later removal by BackupPC_trashClean.
BackupPC_link reads the NewFileList written by BackupPC_dump and inspects each new file in the backup. It re-checks if there is a matching file in the pool (another BackupPC_link could have added the file since BackupPC_dump checked). If so, the file is removed and replaced by a hard link to the existing file. If the file is new, a hard link to the file is made in the pool area, so that this file is available for checking against each new file and new backup.
Then, for incremental backups, hard links are made in the new backup to all files that were not extracted during the incremental backups. The means the incremental dump looks like a complete image of the PC (with the exception that files that were removed on the PC since the last full dump will still appear in the backup directory tree).
Also, once each night, BackupPC_nightly is run to complete some additional administrative tasks, such as cleaning the pool. This involves removing any files in the pool that only have a single hard link (meaning no backups are using that file). Again, to avoid race conditions, BackupPC_nightly is only run when there are no BackupPC_dump or BackupPC_link processes running.
BackupPC also listens for tcp connections on $Conf{ServerPort}, which is used by the CGI script BackupPC_Admin for status reporting and user-initiated backup or backup cancel requests.
BackupPC resides in three directories:
Below __TOPDIR__ are several directories:
Each file is stored in a subdirectory X/Y/Z, where X, Y, Z are the first 3 hex digits of the MD5 digest.
For example, if a file has an MD5 digest of 123456789abcdef0, so the file is stored in __TOPDIR__/pool/1/2/3/123456789abcdef0.
The MD5 digest might not be unique (especially since not all the file's contents are used for files bigger than 256K). Different files that have the same MD5 digest are stored with a trailing suffix ``_n'' where n is an incrementing number starting at 0. So, for example, if two additional files were identical to the first, except the last byte was different, and assuming the file was larger than 1MB (so the MD5 digests are the same but the files are actually different), the three files would be stored as:
__TOPDIR__/pool/1/2/3/123456789abcdef0
__TOPDIR__/pool/1/2/3/123456789abcdef0_0
__TOPDIR__/pool/1/2/3/123456789abcdef0_1
Both BackupPC_dump (actually, BackupPC_tarExtract) and BackupPC_link are responsible for checking newly backed up files against the pool. For each file, the MD5 digest is used to generate a file name in the pool directory. If the file exists in the pool, the contents are compared. If there is no match, additional files ending in ``_n'' are checked. (Actually, BackupPC_tarExtract compares multiple candidate files in parallel.) If the file contents exactly match, the file is created by simply making a hard link to the pool file (this is done by BackupPC_tarExtract as the dump proceeds). Otherwise, BackupPC_tarExtract writes the new file to disk and a new hard link is made in the pool to the file (this is done later by BackupPC_link).
Therefore, every file in the pool will have at least 2 hard links (one for the pool file and one for the backup file below __TOPDIR__/pc). Identical files from different backups or PCs will all be linked to the same file. When old backups are deleted, some files in the pool might only have one link. BackupPC_nighly checks the entire pool and removes all files that have only a single link, thereby recovering the storage for that file.
One other issue: zero length files are not pooled, since there are a lot of these files and on most file systems it doesn't save any disk space to turn these files into hard links.
BackupPC isn't perfect. Here are some limitations of BackupPC:
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. How do commercial backup systems solve this problem?
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?
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. However, since the incremental backups are ``filled-in'' with hard links to look like a complete backup, the server is effectively storing 195 complete backups averaging 3.2GB each, or 624GB in just 87GB of space. If you run du or tar on the data directory, there will appear to be 624GB of data.
If your tape backup system is not smart about hard links an alternative is to periodically dump just the last successful dump for each host to tape. Supporting more efficient tape backup is an area for further development.
However, if a file was deleted by a user after the last full dump, that file will still appear in the ``filled-in'' incremental dump. This is not really a specific problem with BackupPC, rather it is a general issue with the full/incremental dump paradigm. This minor problem could be solved by having smblient list all files when it does the incremental dump. Volunteers anyone?
Comments or suggestions on these issues are welcome.
Please read this section and consider each of the issues carefully.
If you use any of the latter three methods please make sure that the file's permission is appropriately restricted. If you also use RCS or CVS, double check the file permissions of the config.pl,v file.
In future versions there will probably be support for encryption of the smb share password, but a private key will still have to be stored in a protected place. Comments and suggestions are welcome.
A denial-of-service type attack is possible here. Someone could simply connect many times to this port, until BackupPC had exhausted all its file descriptors, and this would cause new backups and the CGI interface to fail.
In future versions there might be an authentication handshake using a shared private key. Comments and suggestions are welcome.
The Apache configuration should be setup for AuthConfig style, using a .htaccess file so that the user's name is passed into the script as $ENV{REMOTE_USER}.
If normal users could directly run BackupPC_Admin then there is a serious security hole: since it is setuid to __BACKUPPCUSER__ any user can browse and restore any backups. Be aware that anyone who is allowed to edit or create cgi scripts on your server can execute BackupPC_Admin as any user! They simply write a cgi script that sets $ENV{REMOTE_USER} and then execs BackupPC_Admin. The exec succeeds since httpd runs the first script as user httpd/apache, which in turn has group permission to execute BackupPC_Admin.
While this setup should be safe, a more conservative approach is to run a dedicated Apache as user __BACKUPPCUSER__ on a different port. Then BackupPC_Admin no longer needs to be setuid, and the cgi directories can be locked down from normal users.
Comments and suggestions are welcome.
The BackupPC configuration file resides in __TOPDIR__/conf/config.pl. Optional per-PC configuration files reside in __TOPDIR__/pc/$host/config.pl. This file can be used to override settings just for a particular PC.
The configuration file is a perl script that is executed by BackupPC, so you should be careful to preserve the file syntax (punctuation, quotes etc) when you edit it. It is recommended that you use CVS, RCS or some other method of source control for changing config.pl.
BackupPC reads or re-reads the main configuration file in three cases:
Whenever you change the configuration file you can either do a kill -HUP BackupPC_pid or simply wait until the next regular wakeup period.
Each time the configuration file is re-read a message is reported in the LOG file, so you can tail it (or view it via the CGI interface) to make sure your kill -HUP worked. Errors in parsing the configuration file are also reported in the LOG file.
The optional per-PC configuration file (__TOPDIR__/pc/$host/config.pl) is read whenever it is needed by BackupPC_dump, BackupPC_link and others.
The configuration parameters are divided into four general groups. The first group (general server configuration) provides general configuration for BackupPC. The next two groups describe what to backup, when to do it, and how long to keep it. The fourth group are settings for the CGI interface.
All configuration settings in the second, third and fourth groups can be overridden by the per-PC config.pl file.
If the hosts you are backing up are always connected to the network you might have only one or two wakeups each night. This will keep the backup activity after hours. On the other hand, if you are backing up laptops that are only intermittently connected to the network you will want to have frequent wakeups (eg: hourly) to maximized the chance that each laptop is backed up.
Examples:
$Conf{WakeupSchedule} = [22.5]; # once per day at 10:30 pm.
$Conf{WakeupSchedule} = [1..23]; # every hour except midnight
$Conf{WakeupSchedule} = [2,4,6,8,10,12,14,16,18,20,22]; # every 2 hours
If you decrease this number after BackupPC has been running for a while you will have to manually remove the older log files.
Examples:
# to specify 192.10.10.20 to 192.10.10.250 as the DHCP address pool
$Conf{DHCPAddressRanges} = [
{
ipAddrBase => "192.10.10",
first => 20,
last => 250,
},
];
# to specify two pools (192.10.10.20-250 and 192.10.11.10-50)
$Conf{DHCPAddressRanges} = [
{
ipAddrBase => "192.10.10",
first => 20,
last => 250,
},
{
ipAddrBase => "192.10.11",
first => 10,
last => 50,
},
];
Typically this is set slighty less than an integer number of days. The time taken for the backup, plus the granularity of $Conf{WakeupSchedule} will make the actual backup interval a bit longer.
Typically this is set slighty less than an integer number of days. The time taken for the backup, plus the granularity of $Conf{WakeupSchedule} will make the actual backup interval a bit longer.
In the steady state, each time a full backup completes successfully the oldest one is removed. If this number is decreased, the extra old backups will be removed.
In the steady state, each time an incr backup completes successfully the oldest one is removed. If this number is decreased, the extra old backups will be removed.
Only one of $Conf{BackupFilesExclude} and $Conf{BackupFilesOnly} can be specified per share. If both are set for a particular share, then $Conf{BackupFilesOnly} takes precedence and $Conf{BackupFilesExclude} is ignored.
This can be set to a string, an array of strings, or, in the case of multiple shares, a hash of strings or arrays. A hash is used to give a list of directories or files to backup for each share (the share name is the key). If this is set to just a string or array, and $Conf{SmbShareName} contains multiple share names, then the setting is assumed to apply to only the first share name.
Examples:
$Conf{BackupFilesOnly} = "/myFiles";
$Conf{BackupFilesOnly} = ["/myFiles"]; # same as first example
$Conf{BackupFilesOnly} = ["/myFiles", "/important"];
$Conf{BackupFilesOnly} = {
"c" => ["/myFiles", "/important"], # these are for "c" share
"d" => ["/moreFiles", "/archive"], # these are for "d" share
}
This can be set to a string, an array of strings, or, in the case of multiple shares, a hash of strings or arrays. A hash is used to give a list of directories or files to exclude for each share (the share name is the key). If this is set to just a string or array, and $Conf{SmbShareName} contains multiple share names, then the setting is assumed to apply to only the first share name.
Examples:
$Conf{BackupFilesExclude} = "/temp";
$Conf{BackupFilesExclude} = ["/temp"]; # same as first example
$Conf{BackupFilesExclude} = ["/temp", "/winnt/tmp"];
$Conf{BackupFilesExclude} = {
"c" => ["/temp", "/winnt/tmp"], # these are for "c" share
"d" => ["/junk", "/dont_back_this_up"], # these are for "d" share
}
To allow for periodic rebooting of a PC or other brief periods when a PC is not on the network, a number of consecutive bad pings is allowed before the good ping count is reset. This parameter is $Conf{BlackoutBadPingLimit}.
Note that bad and good pings don't occur with the same interval. If a machine is always on the network, it will only be pinged roughly once every $Conf{IncrPeriod} (eg: once per day). So a setting for $Conf{BlackoutGoodCnt} of 7 means it will take around 7 days for a machine to be subject to blackout. On the other hand, if a ping is failed, it will be retried roughly everytime BackupPC wakes up, eg, every one or two hours. So a setting for $Conf{BlackoutBadPingLimit} of 3 means that the PC will lose its blackout status after 3-6 hours of unavailability.
To disable the blackout feature set $Conf{BlackoutGoodCnt} to a negative value. A value of 0 will make all machines subject to blackout. But if you don't want to do any backups during the day it would be easier to just set $Conf{WakeupSchedule} to a restricted schedule.
smbclient is from the Samba distribution. smbclient is used to actually extract the incremental or full dump of the share filesystem from the PC.
nmblookup is from the Samba distribution. nmblookup is used to get the netbios name, necessary for DHCP hosts.
Note that stdout buffering combined with huge files being backed up could cause longish delays in the output from smbclient that BackupPC_dump sees, so in rare cases you might want to increase this value.
If you decrease this number after BackupPC has been running for a while you will have to manually remove the older log files.
Administrative users have full access to all hosts, plus overall status and log information.
The administrative users are the union of the unix/linux group $Conf{CgiAdminUserGroup} and the manual list of users, seperated by spaces, in $Conf{CgiAdminUsers}. If you don't want a group or manual list of users set the corresponding configuration setting to undef or an empty string.
Examples:
$Conf{CgiAdminUserGroup} = "admin";
$Conf{CgiAdminUsers} = "craig celia";
--> administrative users are the union of group admin, plus
craig and celia.
$Conf{CgiAdminUserGroup} = "";
$Conf{CgiAdminUsers} = "craig celia";
--> administrative users are only craig and celia".
sprintf() strings,
that each contain a single ``%s'' that will be replaced by the user
name.
$Conf{CgiUserHomePageCheck} should be an absolute file path that is used to check (via ``-f'') that the user has a valid home page. Set this to undef or an empty string to turn off this check.
$Conf{CgiUserUrlCreate} should be a full URL that points to the user's home page. Set this to undef or an empty string to turn off generation of URLs for user names.
Example:
$Conf{CgiUserHomePageCheck} = "/var/www/html/users/%s.html";
$Conf{CgiUserUrlCreate} = "http://myhost/users/%s.html";;
--> if /var/www/html/users/craig.html exists, then "craig" will
be rendered as a link to http://myhost/users/craig.html";.
Craig Barratt <craig@arraycomm.com>
See http://backuppc.sourceforge.net.
Copyright (C) 2001 Craig Barratt
This program is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation; either version 2 of the License, or (at your option) any later version.
This program is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details.
You should have received a copy of the GNU General Public License in the LICENSE file along with this program; if not, write to the Free Software Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA.
|
BackupPC |