Hi,

Marcos Lorenzo de Santiago wrote on 2011-04-14 12:31:08 +0200 [[BackupPC-users] 
Re-read hostname config after DumpPreUserCmd]:
> [...]
> I have a bunch of virtual servers in our platform that I wish to backup. 
> The issue here is that sometimes they're turned on and sometimes they're 
> off. I came out with a solution: modifying the ssh command at login time I 
> can pass another argument with the virtual machine name so I can mount it, 
> chroot to it's disk and make a backup if the machine is turned off.

while I like the idea of being flexible about how to obtain the backup, I
don't see that you would need to modify the configuration at runtime for
that to work. Maybe I'm missing something obvious, but I would imagine either

1.) RsyncClientCmd could do all the work - simply point that to a script
    that sets things up and execs the appropriate 'ssh $host rsync ...'
    command.

2.) DumpPreUserCmd could prepare things (as you are doing now) and write into
    a state file whether a native or chroot backup should be done.
    RsyncClientCmd could be a script that reads that state file and then execs
    the appropriate command like above.

3.) DumpPreUserCmd *can* be Perl code, so you could probably even use it
    to do exactly what you are proposing *without* modifying the BackupPC
    code (meaning if the change is not of general interest, you don't need to
    patch the source to get its benefits; you can put it in the
    configuration) - if you really need it.

You'll have to be smart about PingCmd in any case (probably just ping the
server holding the virtual disk contents?).

Aside from all that, can't you just run the backup in the chroot environment
regardless of whether the virtual machine is running? What kind of
virtualization are we talking about?


I'm not saying your approach doesn't work. It's just that, personally, I'd
find a solution which does not modify the configuration at runtime more
readable (maintainable) and more resilient against errors.


> I wanted also to include this modification under 
> BackupPC_dump as it increases BackupPC's functionality.

I disagree. As I said, I don't see that it makes anything possible that isn't
already. It *does* add a failure case (if a narrow one) and unnecessary work
(if not much) for the vast majority of BackupPC installations. And it could
conceivably break installations if anyone should currently use DumpPreUserCmd
to modify his configuration and rely on it *not* taking immediate effect (not
that I'd expect that, but who knows?).

Regards,
Holger

------------------------------------------------------------------------------
Benefiting from Server Virtualization: Beyond Initial Workload 
Consolidation -- Increasing the use of server virtualization is a top
priority.Virtualization can reduce costs, simplify management, and improve 
application availability and disaster protection. Learn more about boosting 
the value of server virtualization. http://p.sf.net/sfu/vmware-sfdev2dev
_______________________________________________
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/