-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi there,
The workaround based on PingCmd, DumpPostUserCmd, and a custom script to handle the VPN works like a charm. I'm so happy to see it working as expected :) Thank you all (Colin, Les, Russell and Holger) for all your comments and support :) Best regards, Ibon. Abrazo, Ibon. Usa Software Libre, tus úlceras te lo agradecerán Realizado con Software Libre. - -- GPG public key at http://sinanimodelucro.net/ibon_gmail.asc Finderprint: 1761 59B9 6DE6 0402 31B9 1872 178F A6FD 75F9 EB29 El 18/12/14 a las 16:28, Holger Parplies escribió: > Hi, > > Colin Shorts wrote on 2014-12-17 09:17:58 +0000 [Re: > [BackupPC-users] Execute script before backup]: >> On 17/12/14 07:50, Ibon Castilla wrote: >>> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 >>> >>> Hi again, >>> >>> I have tested the workaround proposed by Colin, and I have a >>> comment and a question about it: [...] >> That said, there was a follow-up from Les Mikesell that might >> work better. > > I need to fully agree with this. The suggestion to use > BackupPC_serverMesg has downsides not yet covered here. You lose > the scheduling capabilities of BackupPC. If a backup fails, > BackupPC will retry it. Your cron job won't. BackupPC will keep > track of when full backups are required and when incrementals will > do. Your cron job can emulate that by requesting an "auto" backup > instead of an explicit full or incremental, but that won't work > together with BackupsDisable (see below). BackupPC has settings to > regulate the number of simultaneous backups. A backup initiated > with a serverMesg counts as user backup, not as automatically > scheduled backup. There is no guarantee how close to the serverMesg > the backup will actually be started. > >>> * Comment: the idea was to use BackupPC_serverMesg to launch >>> the backup, and then use that command again to test if the >>> server ended that backup successfully. I've realized that the >>> command just tells the server to launch the backup, but it >>> really doesn't do that action by itself, so I have to ask to >>> the server many times if the backup has finished yet. > > Correct. Even worse, it will only *queue* the backup. Depending on > configuration and other backups running, it could be hours before > the backup even *starts*. This somewhat defeats the whole point, if > your VPN is not guaranteed to survive a long idle period, and even > if it is, you could just as well leave the VPN running permanently. > Starting and stopping it suggests that you don't want it active > outside the backup window. > >>> Instead of BackupPC_serverMesg I've decided to use >>> BackupPC_dump, because this one does the backup by itself. > > By doing that, you lose even more. You do realize that you need to > run a BackupPC_link, and that you cannot safely run that yourself, > don't you? BackupPC will not really be aware of the fact that the > backup has been run outside its control. I believe it will show up > in the web interface by virtue of BackupPC_dump having updated the > backups file, but I'm not sure what statistical values will be > maintained correctly and whether automatic scheduling and error > reporting would work. > > It's simply not the way BackupPC is designed to work. You're really > taking a central piece of BackupPC and throwing the rest away, or > rather, hoping the rest won't interfere. You might be better > advised to just use plain rsync from the start. That won't give you > pooling, compression or a web interface, but it would at least be a > clean and flexible solution. > >>> [...] * Question: to use BackupPC_dump, the host must be >>> defined on the host file. [...] avoid that I've been trying to >>> use $Conf{BackupsDisable} on my_host.pl file. If I set that >>> parameter to 1 or 2, then BackupPC_dump complains about it, >>> saying that the host is configured to avoid backups. > > A value of 1 should disable scheduled backups while still running > manual backups, but you would have to explicitly request full or > incremental backups. What you are trying to do is not really > supported. > >> You might be better to leave the backups enabled and just >> increase the ages (FullPeriod and IncrPeriod) from 6.97 and 0.97 >> respectively, to something a little higher, that way the backuppc >> won't attempt to backup the host as long as your scheduled task >> is working. > > Yes, but it also won't *succeed* in backing up the host when the > scheduled task is *not* working, because it won't set up the VPN > link, so you don't gain the fallback you are aiming at. Setting > FullPeriod and IncrPeriod to really high values (say 10000 = almost > thirty years) should avoid automatic backups, unless, of course, > something strange happens to your system clock ;-). > > Regards, Holger > > ------------------------------------------------------------------------------ > > Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server > from Actuate! Instantly Supercharge Your Business Reports and > Dashboards with Interactivity, Sharing, Native Excel Exports, App > Integration & more Get technology previously reserved for > billion-dollar corporations, FREE > http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk > > _______________________________________________ > BackupPC-users mailing list [email protected] > List: > https://lists.sourceforge.net/lists/listinfo/backuppc-users Wiki: > http://backuppc.wiki.sourceforge.net Project: > http://backuppc.sourceforge.net/ > -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) iEYEARECAAYFAlSYChAACgkQF4+m/XX56ykCgQCfboJSqO0q1mjBbt/hZo8jXZP4 SjQAnR+vT7f73oK8BdGeurhCr/4eMg+5 =Ey7A -----END PGP SIGNATURE----- ------------------------------------------------------------------------------ _______________________________________________ BackupPC-users mailing list [email protected] List: https://lists.sourceforge.net/lists/listinfo/backuppc-users Wiki: http://backuppc.wiki.sourceforge.net Project: http://backuppc.sourceforge.net/
