-----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 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/
>
-----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
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/
|
