(a fork of Attic)
"The holy grail of backup software?"
Thomas Waldmann (07/2017)
authenticated encryption
easy pruning of old backups
simple backend (k/v, fs, via ssh)
FOSS (BSD license)
good docs
good platform / arch support
Linux, *BSD, OS X, OpenIndiana, Cygwin, Win10 Linux Subsystem, HURD -
native Windows port still unfinished / not merged yet into master.
FUSE support ("mount a backup")
developed by "The Borg Collective"
more open development
new developers are welcome!
quicker development
redesign where needed
changes, new features
incompatible changes with good reason,
minor things at minor, major at major releases
thus: less "sta(b)le"
attic repo: ~600 changesets
packaged for many Linux distributions
also in *BSD and Mac OS X dists
more or less works on Windows w/ Cygwin
Happy users on Twitter, Reddit and the Blogosphere.
test scalability / reliability / security
be careful!
find, file and fix bugs
file feature requests
improve docs
contribute code
spread the word
create dist packages
care for misc. platforms
borgbackup.org
#borgbackup on chat.freenode.net
Just grab me at the conference!
Thomas J Waldmann @ twitter
borg does error (and even tampering) detection
but not (yet?) error correction
kinds of errors / threat model:
single/few bit errors
defect / unreadable blocks
media failure (defect disk, ssd)
see issue #225 for discussion
implement something in borg?
rely on other soft- or hardware solutions?
avoid futile attempts
sha256, hmac-sha256, crc32 are slow
aes is also slow, if not hw accelerated
faster: poly1305, blake2, sha512-256, crc32c, chacha20
we will support OpenSSL 1.1 for better crypto:
aes-ocb / aes-gcm
chacha2-poly1305
also use blake2b (borg 1.1)
see PR #1034 crypto-aead branch
currently:
1 AES key
1 HMAC key
1 chunker seed
stored highest IV value for AES CTR mode
encrypted using key passphrase
borg >= 1.0 now has lower RAM consumption
chunks, files and repo index kept in memory
uses bigger chunks (2MiB, was: 64kiB)
less chunks to manage -> smaller chunks index.
be careful on small machines (NAS, rpi, ...)
or with huge amount of data / huge file count
in the docs, there is a formula to estimate RAM usage
own hash table implementation in C
compact block of memory, no pyobj overhead
e.g. used for the chunks index, repo index
uses closed hashing (bucket array, no linked lists)
uses linear probing for collision handling
sometimes slow (maybe when HT full of tombstones?)
use Robin Hood hashing?
HT performance difficult to measure
problem: multiple clients updating same repo
then: chunk index needs to get re-synced
slow, esp. if remote, many and/or big archives
local collection of single-archive chunk indexes
needs lots of space, merging still expensive
idea: "borgception"
backup chunks index into a secondary borg repo
fetch it from there when out of sync
idea: "build chunks index from repo index" (in 1.1)
repo index knows all chunk IDs
but: no size/csize info in repo index
1.2.3 (tagged release code)
1.2.4.dev3+gdeadbee (3 commits later)