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:passw...@www.foo.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@lists.sourceforge.net List: https://lists.sourceforge.net/lists/listinfo/backuppc-users Wiki: http://backuppc.wiki.sourceforge.net Project: http://backuppc.sourceforge.net/