Hi,
madams9 wrote on 2015-10-11 15:28:21 -0700 [[BackupPC-users] BackuPC with
Monit]:
> [...]
> At any rate, I have a BackupPC installation on a server in a closet. It is
> connected to the network wirelessly. I understand the implications but
> remember - this is my personal network in my home and there is nothing
> mission critical for that backup server.
well, "mission critical" is certainly one point (*), but the other one - the
one you are trying to solve - is ease of administration. An ethernet connection
is, in general, simply rock solid. Ask anyone operating Linux servers. Reboots
are for kernel security updates or hardware upgrades mostly, occasionally for
resetting misbehaving hardware, but my feeling tells me ethernet cards are
near the bottom of the list. I've got a server at hand with an uptime of 881
days - evidently missing security updates. What happened 881 days ago? The
hardware was replaced. Network problems since then: zero.
I have seen flaky hardware losing an ethernet connection (i.e. unreachable
from the network though locally responsive), but that is a rare exception
in my experience.
The second point is that I recall numerous reports on this list of people
having problems with backups of *clients* connected via WLAN. There is really
not much difference where between the server and the client the wireless
connection is, but experience seems to show that backups will (occasionally)
fail and/or be (much) slower than expected.
It's fine if you can detect problems with your wireless network and restart
services accordingly, but that will almost definitely interrupt a backup in
progress, and if you're unlucky, there might be corner cases where this can
go undetected, leading to inconsistent backups (as in "the one full backup
that will be kept for ages contains only the first few files").
All of that said, there might be valid reasons for sticking to the wireless
connection, and my points may be non-issues for you.
> [...]
Carl Wilhelm Soderstrom wrote on 2015-10-12 12:00:12 -0400 [Re:
[BackupPC-users] BackuPC with Monit]:
> On 10/11 03:28 , madams9 wrote:
> > ## BACKUP PC
> > check process backuppc with pidfile "/var/log/backuppc/BackupPC.pid"
> > start program "/usr/sbin/service backuppc start"
> > stop program "/usr/sbin/service backuppc stop"
> > if failed host adamsmdk port 16073 proto http then restart # change if not
> > listening locally
> > ###
> >
> > Obviously, that last line is trash because the backuppc socket process
> > starts a different port everytime it's initiated.
Does it? If I read the code correctly, BackupPC uses a Unix domain socket and
only opens an additional TCP socket if a port is specified in the config file,
to which it then binds. So you either have no TCP socket at all, or you have
one bound to a fixed port. Of course, your packaged version of BackupPC may
vary (though I'm not sure why it should).
> > Aside from that, I have no idea how monit is supposed to test for the
> > presence of backuppc.
>
>
> Hmm, the stock monitrc file provides the following suggestion among others:
> # if failed url http://user:password AT www.foo DOT bar:8080/?querystring
> # and content == 'action="j_security_check"'
>
> So perhaps monit could log into the BackupPC host and check one of bpc's
> output pages for certain content.
The problem with that is that it checks for a running web server, not a
running BackupPC daemon (well, unless the requested web page in turn tries to
contact the server, in which case you'd have to parse the result out of the
web page). If the web server is, in fact, down, you would keep restarting
the BackupPC daemon, which won't help.
I'd rather use something like
sudo -u backuppc /usr/share/backuppc/bin/BackupPC_serverMesg status
and check the return code. You might need to adjust the path and redirect
output to /dev/null (and, of course, set up sudo to allow that without
password). And please test that before depending on it :).
Have you actually observed problems with the BackupPC daemon that *don't* show
up immediately on startup? The usual (startup) failures that spring to mind
would seem to require manual intervention rather than a simple restart via the
init script.
Regards,
Holger
(*) One more note on "mission critical": it might not seem so now, but if you
were to, one day, find out that that one file you would have needed to
restore just isn't in your backups in a sufficiently recent version, you
*would* ask yourself why you went to the cost and trouble of doing regular
automatic backups in the first place.
------------------------------------------------------------------------------
_______________________________________________
BackupPC-users mailing list
BackupPC-users AT lists.sourceforge DOT net
List: https://lists.sourceforge.net/lists/listinfo/backuppc-users
Wiki: http://backuppc.wiki.sourceforge.net
Project: http://backuppc.sourceforge.net/
|
