[Borgbackup] [Documentation] Remote/ local usage

Sitaram Chamarty sitaramc at gmail.com
Thu Sep 8 01:45:59 EDT 2016


On 09/08/2016 10:50 AM, tmhikaru at gmail.com wrote:
> On Wed, Sep 07, 2016 at 08:58:57AM +0200, nerbrume at free.fr wrote:
>> Hello,
>>
>> I've just setup borg between a rather recent desktop machine (local), which is distantly backuped (ssh) on a very small box (something like a raspberry pi 1st gen, but with even less RAM).
>> I didn't found in the documentation any reference as to which operations are done where (and what parameters I can act upon to lessen the burden on the slow distant machine).
>> (btw, the doc is great !)
>>
>> My main concerns are the CPU and RAM usage during backup (I guess disk usage would be of interest too, but I didn't found it to be the limiting factor) : 
>> - where is the compression (lz4/gzip/lzma) done ?
>> - where is the encryption (ssh + borg own encryption) done ?
>> - where is the deduplication done ?
> 
> Taking it from someone who tried using borg to do backups from an rpiB1
> client to a powerful server, these are all operations that are done client
> side, and in theory should work in your described scenario though you will
> get a bit of a speed hit with I/O.  ...  Just don't try to use it the other
> way around, it just does not work well trying to run the client on a weak
> machine, when it works at all.  I never did figure out why it kept
> inexplicably hanging forever.
> 
> If you have problems with server side operations taking forever, never
> completing or running out of memory, you may want to try using sshfs instead
> of a more typical borg over ssh login.  Using sshfs will allow you to access
> the remote repo via borg as if it was locally present on the client machine,
> and will not require borg to be installed or run on the server.  It will
> require quite a bit more computation out of ssh than normal, but in practice
> I found that making the weak machines files accessable via sshfs *greatly*
> sped things up compared to having it run the program over an ssh login.
> 
> As an alternative, you may want to consider rsync if borg does not work out
> for you.  Although it does not support backing up selinux xattrs, doesn't
> have a way to encrypt files, and doesn't have the deduplication awesomeness
> of borg, on a weaker machine it actually works where borg cannot.  You can
> even have it use hardlinks to do incremental backups, though this requires
> semicomplicated scripting.  I personally had to revert to using rsync for my
> backups because I could not expect borg to work on the weak client machine -
> it hardly did me any good to have a backup that could not be restored. 
> Luckily in your case it sounds like this won't be a problem.

I combined the two once (different problem but still...).  I did a borg
backup locally, then rsync-d that (with "--delete")  to the remote
server.

regards
sitaram


More information about the Borgbackup mailing list