Backup Central

I'm interested in customizing BackupPC's archive feature to send the data to Tarsnap instead of creating a local tarball. Has anyone tried this kind of integration? I understand that I need to change BackupPC_tarCreate, but I'm trying to figure out what the parameters that get passed to it actually represent. Does BackupPC_tarCreate get a filesystem view of the backup's contents or is it creating that itself?

Maybe it would be easier to just explode the tarball that the standard archive process creates and then call into Tarsnap, but that seems inefficient. I don't need the archive file.

On Fri, Feb 10, 2012 at 9:05 AM, Rob Hasselbaum <rob < at > hasselbaum.net ([email]rob < at > hasselbaum.net[/email])> wrote:
I'm interested in customizing BackupPC's archive feature to send the data to Tarsnap instead of creating a local tarball. Has anyone tried this kind of integration? I understand that I need to change BackupPC_tarCreate, but I'm trying to figure out what the parameters that get passed to it actually represent. Does BackupPC_tarCreate get a filesystem view of the backup's contents or is it creating that itself?

Maybe it would be easier to just explode the tarball that the standard archive process creates and then call into Tarsnap, but that seems inefficient. I don't need the archive file.


I don't know anything about tarsnap but it looks like it has its own way of tracking incremental changes.  Is there some reason you can't just run it independently from the original source?    Someone has mentioned a fuse filesystem that works on top of the backuppc archive on the list before - that might work if you have to use backuppc's copy.


--
  Les Mikesell
    lesmikesell < at > gmail.com ([email]lesmikesell < at > gmail.com[/email])

On Fri, Feb 10, 2012 at 10:46 AM, Les Mikesell <lesmikesell < at > gmail.com ([email]lesmikesell < at > gmail.com[/email])> wrote:
I don't know anything about tarsnap but it looks like it has its own way of tracking incremental changes.  Is there some reason you can't just run it independently from the original source?    Someone has mentioned a fuse filesystem that works on top of the backuppc archive on the list before - that might work if you have to use backuppc's copy.



One of the things I like about Tarsnap compared to other off-site backup services is that it's nicely scriptable so I can manage what gets backed up and when from one central server just like BackupPC itself. By the same token, though, Tarsnap is not very convenient to run from the individual PCs because some of them are Windows and I'd need to deploy scripts to run it periodically through Cygwin.

I'll take a look at the FUSE filesystem. Thanks for the tip! I'm guessing, though, that it won't be any more efficient than just exploding the archive to a /tmp directory and having Tarsnap walk through it there.

Rob Hasselbaum wrote at about 11:37:49 -0500 on Friday, February 10, 2012:
On Fri, Feb 10, 2012 at 10:46 AM, Les Mikesell <lesmikesell < at > gmail.com>wrote:

I don't know anything about tarsnap but it looks like it has its own way
of tracking incremental changes. Is there some reason you can't just run
it independently from the original source? Someone has mentioned a fuse
filesystem that works on top of the backuppc archive on the list before -
that might work if you have to use backuppc's copy.


One of the things I like about Tarsnap compared to other off-site backup
services is that it's nicely scriptable so I can manage what gets backed up
and when from one central server just like BackupPC itself. By the same
token, though, Tarsnap is not very convenient to run from the individual
PCs because some of them are Windows and I'd need to deploy scripts to run
it periodically through Cygwin.

I'll take a look at the FUSE filesystem. Thanks for the tip! I'm guessing,
though, that it won't be any more efficient than just exploding the archive
to a /tmp directory and having Tarsnap walk through it there.

Be aware that the BackupPC FUSE filesystem while incredibly useful and
slick, is also quite slow since the directories and file attributes
need to be read from the compressed attrib files.

It's great for browsing backups manually using *nix tools and it's
good for short scripts. It likely will be unbearably slow for tarring
an entire backup filesystem. It still would be instructive to try it
and see how much of a performance penalty it introduces.

------------------------------------------------------------------------------
Virtualization & Cloud Management Using Capacity Planning
Cloud computing makes use of virtualization - but cloud computing
also focuses on allowing computing to be delivered as a service.
http://www.accelacomm.com/jaw/sfnl/114/51521223/
_______________________________________________
BackupPC-users mailing list
BackupPC-users < at > lists.sourceforge.net
List: https://lists.sourceforge.net/lists/listinfo/backuppc-users
Wiki: http://backuppc.wiki.sourceforge.net
Project: http://backuppc.sourceforge.net/

On Fri, Feb 10, 2012 at 10:37 AM, Rob Hasselbaum <rob < at > hasselbaum.net ([email]rob < at > hasselbaum.net[/email])> wrote:
 
One of the things I like about Tarsnap compared to other off-site backup services is that it's nicely scriptable so I can manage what gets backed up and when from one central server just like BackupPC itself. By the same token, though, Tarsnap is not very convenient to run from the individual PCs because some of them are Windows and I'd need to deploy scripts to run it periodically through Cygwin.

Can you cifs-mount them into the server handling the backups to get semi-direct access?

--
   Les Mikesell
     lesmikesell < at > gmail.com ([email]lesmikesell < at > gmail.com[/email])

On Fri, Feb 10, 2012 at 2:06 PM, Les Mikesell <lesmikesell < at > gmail.com ([email]lesmikesell < at > gmail.com[/email])> wrote:


Can you cifs-mount them into the server handling the backups to get semi-direct access?




Had not considered that. Might be a possibility. Ideally, I'd still like to leverage the BackupPC backups because I've already defined what I want to include in there, but that's a good Plan B.


 

On Fri, Feb 10, 2012 at 2:40 PM, Rob Hasselbaum <rob < at > hasselbaum.net ([email]rob < at > hasselbaum.net[/email])> wrote:
On Fri, Feb 10, 2012 at 2:06 PM, Les Mikesell <lesmikesell < at > gmail.com ([email]lesmikesell < at > gmail.com[/email])> wrote:


Can you cifs-mount them into the server handling the backups to get semi-direct access?





Had not considered that. Might be a possibility. Ideally, I'd still like to leverage the BackupPC backups because I've already defined what I want to include in there, but that's a good Plan B.



If I were doing it, I'd look at backuppc as the local backup copy and tarsnap or other remote system as the disaster recovery backup that you would only use if the primary system is gone.  Making one depend on the other gives you a single point of failure for both.

--
   Les Mikesell
      lesmikesell < at > gmail.com ([email]lesmikesell < at > gmail.com[/email])

On Fri, Feb 10, 2012 at 4:50 PM, Les Mikesell <lesmikesell < at > gmail.com ([email]lesmikesell < at > gmail.com[/email])> wrote:

If I were doing it, I'd look at backuppc as the local backup copy and tarsnap or other remote system as the disaster recovery backup that you would only use if the primary system is gone.  Making one depend on the other gives you a single point of failure for both.





That is what I'm doing. Restoring from Tarsnap doesn't require the BackupPC server to be intact so there's no single point of failure.

In any event, I got it working. It turns out Tarsnap can consume tarballs directly. No need to point it to a filesystem.