Re: [BackupPC-users] New user- loads of questions

[Holger P. <wb...@pa...>]

Hi,

Nigel Kendrick wrote on 2009-08-18 12:04:16 +0100 [[BackupPC-users] New user- loads of questions]:
> I have just started to play with backuppc and am making good strides - local
> (SMB) backups are working fine

I hope you mean SMB backups of local Windoze machines, not of the BackupPC
server ;-). In any case, welcome to BackupPC.

> [...]
> 1) I presume(?) SMB-based backups cannot do block-difference-level copies
> like rsync? We have a number of remote (over VPN) Windows servers and I'd
> like to backup their MSSQL database dumps - they are around 700MB at the
> moment and I presume via SMB the whole lot will get transferred every time?

Correct. I'm not sure how well rsync will handle database dumps, though. You
should try that out manually (if you haven't done so already). Please also
remember that BackupPC will store each version independently, though possibly
compressed (i.e. BackupPC only does file-level deduplication, not block-level).
You only save bandwidth with rsync on transfer, not on storage.

> 2) I have seen a number of guides for cwrsync on Windows-based PCs. Any
> votes on the best one and the best place to read up on this? I presume that
> since we'd be backing up via VPN, we could run rsync directly rather than
> via an SSH tunnel?

As far as I know, rsync doesn't work correctly on Windoze (rsyncd does,
though). With a VPN, I'd definitely recommend plain rsyncd. I don't backup
Windoze myself, but Deltacopy is mentioned often on the list - there's a
thread from today [rsyncd on Vista 64-bit cygwin vs SUA] which you might want
to check out.

> 3) As the remote sites are linked via VPN, I could mount the remote shares
> to the local backup server and use rsync 'directly' - any pros/cons doing
> things this way (speed, reliability etc?), or is an rsync server on the
> remote servers a better approach?

If you mount the remote shares locally, you lose the benefit of the rsync
protocol *completely*, because the "remote" rsync instance is running on the
local computer and will need to read each whole file over the network in order
to figure out which blocks don't need to be transferred (locally) ;-). You
still get better backup precision on incrementals than with tar, but a remote
rsync server (or rsync over ssh for UNIX clients) is definitely the better
approach. I can't think of any advantages of mounting the remote shares,
except that it may be slightly easier to set up (but does that count?).

> 4) I am running the backup server on CentOS 5.3 and installed backuppc from
> the Centos RPM. Ideally I'd like to run the app as the normal 'apache' user
> - I read up on a few generic notes about doing this and got to a point where
> backuppc wouldn't start properly as it couldn't create the LOG file. I then
> went round in circles looking at file permissions before putting things back
> the way they were in order to do some more learning. Is there a
> simple-to-follow guide for setting up backuppc to not use mod_perl - I have
> read the docs but am still not getting there.

I believe the default *is* for BackupPC to *not* use mod_perl. Your RPM may
differ, but the upstream documentation will not reflect this.

The BackupPC CGI script needs to be run as backuppc user for various reasons
(access to the pool FS, access to the BackupPC server daemon, use of the
BackupPC Perl library), so you can either run the web server as backuppc user
or implement some form of changing UID (the CGI script - BackupPC_Admin (or
index.cgi on Debian, don't know about Centos) - is normally setuid backuppc,
but that can't work with mod_perl, I believe).

Do you have a reason for not wanting to run apache as backuppc user (eg. other
virtual hosts)? I'm no apache expert, but *removing* use of mod_perl is bound
to be easier than getting it set up (I never did set it up, though). Just make
sure that your changes are not lost if you, one day, decide to upgrade the RPM
package. Backing them up with BackupPC is a good idea, but remember that at
the point where you would need to access them, your web interface would not be
working ...

Regards,
Holger