|
|
|
|
If you have multiple disks, some reserved for BackupPC, then it makes sense to backup the remaining disks to BackupPC.
Even if you haven't installed dedicated disks for BackupPC's data, backing up the non-BackupPC parts of your file systems provides protection from inadvertently deleted data.
The three issues are:
Don't backup the BackupPC data directory! This recursion will steadily fill up your disk. Make sure you set $Conf{SmbShareName}, $Conf{BackupFilesExclude} or $Conf{BackupFilesOnly} so that the BackupPC data directory is not backed up.
Decide on the $Conf{XferMethod}, most likely tar, rsync or rsyncd.
In some case, although not likely, you might need to set $Conf{ClientNameAlias} to 'localhost' if the XferMethod can't contact the host by regular host name.
If you want to use tar or rsync, you will need to run these programs as root (user id 0). This elevation of user privileges can be done will ``ssh HOST -l root'' like any other client. But then ssh will needlessly encrypt all the network traffic, which is not necessary in this case.
Daniel Poelzleithner suggests the alternative of using sudo, so there is no overhead with ssh. For example:
$Conf{TarClientCmd} = '/usr/bin/sudo $tarPath -c -v -f - -C $shareName+ --totals';
Then run visudo to give BackupPC permission to run sudo without a password, but only be able to run the /bin/tar command. For example, add this line:
backuppc ALL = NOPASSWD: /bin/tar
Note that an attacker who can become the backuppc user can then use sudo to run /bin/tar as root. Importantly, this means they can write files anywhere on the file system by doing tar -x. This allows them to become root.
If you want to be more cautious, you could create a short shell script (eg: tarCreate) that includes the create argument arguments from $Conf{TarClientCmd}, eg:
#!/bin/sh -f
exec /bin/tar -c $*
Make sure this script and all parent directories have no write permission. Then remove the -c from $Conf{TarClientCmd} and change the tar path:
$Conf{TarClientCmd} = '/usr/bin/sudo /path/to/tarCreate -v -f - -C $shareName+ --totals';
Finally, run visudo to change the allowed command to /path/to/tarCreate.
In this case, a compromise of the backuppc user still allows the attacker to run tar -c. But this only allows them read access to files on the server, which they already have access to simply by inspecting the BackupPC backup data directories.
A similar setup with sudo can be used for rsync. See the SSH FAQ for more information.