----- Original Message -----
> From: "shorvath" <
backuppc-forum AT backupcentral DOT com>
> To:
backuppc-users AT lists.sourceforge DOT net
> Sent: Tuesday, June 26, 2012 6:02:57 PM
> Subject: [BackupPC-users] Offsite copy
>
> Hi Timothy,
>
> Thanks for your comments, unfortunately however I think you're
> missing my point.
> I very much like the way Backuppc handles backup, dedupe etc. and to
> use this on the local site to handle the backups of each individual
> client would be preferred, plus it gives the client an interface to
> browse backups and do restores. (One of the main reasons I want to
> use it)
> However for remote backups (eg offsite) I want to be able to have and
> rsync style "snapshot" of the most recent backup.
> I do not want to have to pull backups from my remote site to each
> individual server for this purpose because
> A) I'm already backing them up from the local site backup server and
> I don't want to back them up twice (more io/cpu and it'll take
> longer) These servers are production and heavily used with a lot of
> daily changes.
> Keep in mind that the backup server is used just for backups so it
> can spend the whole day getting thrashed for all I care.
> and to be honest that just seems silly and more than a solution.
> B) I don't like having multiple entry points ..... actually no other
> points are needed. Point A is enough reason not to do it.
> I already achieve my needs currently by simply using rsync for both
> local and remote but as mentioned earlier I want a more elegant
> solution and I like backuppc and how it handles the local backups.
> If there is no way of exposing the latest backup of each host from
> the backuppc server either via a fuse module (that works) or other
> means then my solution to either stick to my current solution. eg
> rsync but spend some time refining it.
> or
> use something like rdiff-backup or rsnapshot.
> rdiff-backup will allow me to see the most recent "snapshot" but has
> it's caveats/pitfalls/complexities.
> Rsnapshot will do everything I need but maybe not the most efficient
> on space.
> Of course there are other...
> Bandwidth, not a problem, I can limit/shape that several ways.
>