[Box Backup] Backuping inversely

[Pablo Fernandez]

Hi

Thanks for the information.

Think about it from the perspective of a system administrator of a
cluster where the number of nodes grows. Keeping the schedule of backups
in clients becomes unmanageable and having a central scheduler would
make the job much easier. I like the assumption that the server is
unsecure, but I think what is mostly unsecure is the storage, not the
server itself, as long as the data is only accessible to the client I
don't think it would be a negative impact to allow the server to control
when backups are made. 

Thanks

Best regards,
Pablo


On Fri, 2008-01-25 at 22:19 +0000, Chris Wilson wrote:
> Hi Pablo,
> 
> On Fri, 25 Jan 2008, Pablo Fernandez wrote:
> 
> > I would like to implement backups in the inverse fashion to box backup 
> > normal behavior.
> > 
> > I would like to have a server that triggers the backups from clients and 
> > disallow clients to trigger backups on their own. Instead of push I 
> > would like to do a pull of the data. Is it possible to do this?
> 
> It's not supported at all at the moment. The general philosophy of Box 
> Backup is that the server is "untrusted", and therefore that you wouldn't 
> want to place the control of backup scheduling in its hands.
> 
> Having said that, there are a few ways that it could be implemented 
> reasonably easily:
> 
> * Get the server to SSH to the client and run "bbackupctl sync".
> 
> * Have a "reverse connection" mode where the server can connect to the 
>   client, which then logs in over the same connection.
> 
> * Have the client send a "SyncAllow"-type command to the server before 
>   starting the backup, to which the server could respond "backup now" or 
>   "wait X seconds".
> 
> The first does not require any changes to Box, so it's what I'd recommend 
> that you try if you want this feature now. I can't see much use for the 
> feature so I'm not really inclined to implement either of the other two 
> options unless I see more people asking for it. (Especially not before 
> releasing 0.11).
> 
> Cheers, Chris.