autobd is an automated, networked and containerized backup solution

![autobd] (logo.png?raw=true "autobd")

Backing you up since whenever...

Go Report Card Stories in Ready Build Status GoDoc Gitter

What is it?

Autobd is an automatic backup daemon. What is that? A daemon (derived from the evil word 'demon') is a process or program that runs (mostly) silently in the background, and handles certain tasks. This 'Demons' task is to back up a directory tree.

Say you have three servers. A, B and C. You have files on server A that you want on servers B and C. You don't really want to some convoluted and hacky script, you need something that is just going to work in the background, require almost no configuration or installation of any additional software, and is super easy to get running via docker.

Enter Autobd.

All you need to do on server A is set the directory you want to watch via the DATA_DIR variable in scripts/docker/deploy-server.sh, then you can start the daemon by running this script. This will start a single autobd server instance, running inside of docker. You can curl http://0.0.0.0:8080/version, and you will get version information from the server.

Now you just need to get your nodes going. This is just like the server, except you're using another script, pre-written. All you need to do is let the node know which directory you want it to put synced files into, via the DATA_DIR variable in the scripts/docker/deploy-nodes.sh script and run the it. You're good to go.

Once the nodes and server are running, the nodes will identify with the server, and request an initial file index from there server. The first sync of course will be quite large, since the node is getting everything, but subsequent syncs will usually be much smaller, unless you dump a lot of files onto the server at once.

The nodes will do this again and again in an interval, that you can define in etc/config.toml.node. Additionally, each node will send the server a 'heartbeat' in an interval. This lets the server know of the status of each node, if it's synced, and if it's still online. So you need only access the server, to get information on the entire 'horde' of 'demons' :)

That's autobd in a nutshell.

See the tutorial for a more in-depth guide.

Getting autobd

Golang is required, so get that. Most versions should work but it's probably best to stick with at least 1.4.2 as that's what I'm developing on.

After you have go installed, it's as simple as either cloning the git repo:

git clone https://github.com/tywkeene/autobd

or using go get:

go get github.com/tywkeene/autobd

and to build

$ cd autobd
$ ./build.sh

Getting it running

To run autobd , simply do: ./autobd -config etc/config.toml

Autobd ships with two configuration files, config.toml.server and config.toml.node, to get you started running both

Dockerfile

Autobd ships with two Dockerfiles and the scripts to deploy both server and node containers. You'll of course need docker

scripts/docker/deploy-server.sh

Usage: ./scripts/docker/deploy-server.sh

Removes old autobd-server container, builds a new image, and deploys a new autobd-server container using the arguments:

DATA_DIR="/home/$USER/data/server-data"
SECRET_DIR="/home/$USER/secret"
ETC_DIR="/home/$USER/etc/autobd"
PORT=8080

These variables may be modified to suit your needs.

scripts/docker/deploy-nodes.sh

Usage: ./scripts/docker/deploy-nodes.sh n

Builds new autobd-node images, and deploys n nodes

scripts/docker/kill-nodes.sh

Usage: ./scripts/docker/kill-nodes.sh n

Runs docker rm -ffor n nodes

scripts/docker/setup-network.sh

Usage ./scripts/docker/setup-network.sh

Sets up a docker network for server and nodes to communicate. (I basically just use this testing, may or may not be useful to you)

The API

See API.md

Contributing

Open a pull request or issue with your idea or bug. Really. Anything wrong with anything anywhere, open a ticket and let me know, then we can work on it together :) (Just be sure to check the story board before creating a new ticket) and checkout the Development Process flowchart.

Comments
  • Fixes #51

    Fixes #51

    Buffered read of input file for SHA512 calculation instead of loading the entire file into memory first.

    This fixes issue #51, and reduces memory usage of checksumming by a huge margin.

    OK, last pull request wasn't branched right, messed up my local git tree. This one should work fine.

  • Golang Dep incompatible with Go versions 1.5 and 1.6

    Golang Dep incompatible with Go versions 1.5 and 1.6

    https://travis-ci.org/tywkeene/autobd/jobs/198364129 https://travis-ci.org/tywkeene/autobd/jobs/198364130

    Looks like older version of Go can't build the dep tool I picked.

    Considering changing my choice to something a little more fleshed out.

  • Migrate to newer version of ishell dependency

    Migrate to newer version of ishell dependency

    https://github.com/abiosoft/ishell used in cmd/cmd.go (The autobd command line interface) updated at some point and is now broken.

    I've went ahead and rolled over to a preserved version that still works, but I should probably migrate sooner rather than later. Blah.

  • dirty git version in container

    dirty git version in container

    The git tree is detected as dirty in the build script if built in a container. Both the travis builder and the container built by the Dockerfile shipped with autobd produce this behavior.

  • Refactor vet argument

    Refactor vet argument

    Given that we've already installed glide, we can refactor using glide's novendor command:

    Replace this $(go list ./... | grep -v ./vendor) with this $(glide novendor)

  • Development process freeze and changes

    Development process freeze and changes

    So I've been doing horrible keeping to the Semantic Versioning scheme, and some pretty basic development processes. i.e testing, making sure code is in the right branch at the right time, adding too many things at once, ...

    After an enlightening conversation, I've decided to halt the addition of any new features, test what is currently in the dev branch (will be merged to feature-freeze for testing), merge that to master, and reset the version to 0.0.0 to keep things clean.

    Thanks to Jason for showing me the way, this is how the new development process will go.

    • Make goals into written user stories, with clear tests to declare an issue complete
    • Group stories into sprints, to create a milestone for project achievements
    • Create code repository, no code committed without a user story or bug report
    • Commit code at every new feature or fix, commit often
    • All devs have access to all history, so that new problems can be easily stepped back and resolved
    • As people test and experience the product, constantly add new issues, bunch into sprints, and create rapid releases (I like to release every Friday)
    • Dev (on local workstations or handsets), Staging (distributed to a test team), and Production (live, real world)
    • End user problem reporting system, so that real users can easily submit suggestions and bug reports

    So it's gonna go like this

    • [x] - Freeze everything
    • [x] - Merge dev into feature-freeze
    • [x] - Find a way to manage and keep dependencies up to date to avoid unexpected breakage
    • [x] - Adopt and integrate a proven testing framework that fits the autobd's needs (sticking to the base golang testing process)
    • [x] - Start signing commits via my gpg key
    • [x] - Reset versions (Everything. api, cli and node) to 0.0.0
    • [x] - Write tests for:
      • [x] - Server side API (api/api.go)
      • [x] - Client side interaction with the API (node/node.go & client/client.go)
      • [x] - The directory tree indexer (index/index.go)
    • [x] - Reorganize the scripts/ directory. It's getting pretty bad
    • [x] - Refactor/Clean and remove any blaringly bad code, then obviously test it all again.
    • [x] - Refactor the API to actually be RESTful instead of using GET for everything.
    • [x] - Add commit hooks to ensure no code is ever committed without being properly tested
    • [x] - Merge feature-freeze into master
    • [x] - Merge master into dev
    • [x] - Restart development using new rules.

    I should probably also write an in depth step by step guide (DEV.md) so I don't get back out of line.

  • Reduce index/GetIndex() memory usage

    Reduce index/GetIndex() memory usage

    As it is now, index/GetIndex()'s memory usage is insane. I've already had two OOM kills and a deadlock. No bueno. Gonna need to find a way to reduce this drastically. Kinda puts everything on hold, especially issue #58

  • Fixes #51

    Fixes #51

    Buffered read of input file for SHA512 calculation instead of loading the entire file into memory first.

    This should fix the out of memory error, much more efficient this way.

    I'm not sure how your dev cycle works, do you want incoming pulls to go to the dev branch or master?

    edit: Whoops, sorry, messed up an import path with autoimports from editor.

    disregard this, mistaken branch

  • Can't generate checksums for large files

    Can't generate checksums for large files

    Autobd-sever chokes on generating a sha512 checksum for large files (>1GB)

    Autobd (API 0.0.6) (Node 0.0.6) (git commit 3dd117eba4-dirty)
    fatal error: runtime: out of memory
    
    runtime stack:
    runtime.throw(0x6f1d8e, 0x16)
        /usr/lib/go/src/runtime/panic.go:566 +0x95
    runtime.sysMap(0xc4fa2e0000, 0x6d0f0000, 0x0, 0x8589d8)
        /usr/lib/go/src/runtime/mem_linux.go:219 +0x1d0
    runtime.(*mheap).sysAlloc(0x83f4c0, 0x6d0f0000, 0x40e949)
        /usr/lib/go/src/runtime/malloc.go:407 +0x37a
    runtime.(*mheap).grow(0x83f4c0, 0x36871, 0x0)
        /usr/lib/go/src/runtime/mheap.go:726 +0x62
    runtime.(*mheap).allocSpanLocked(0x83f4c0, 0x36871, 0x45102a)
        /usr/lib/go/src/runtime/mheap.go:630 +0x4f2
    runtime.(*mheap).alloc_m(0x83f4c0, 0x36871, 0x7f0100000000, 0x7ffed2029a68)
        /usr/lib/go/src/runtime/mheap.go:515 +0xe0
    runtime.(*mheap).alloc.func1()
        /usr/lib/go/src/runtime/mheap.go:579 +0x4b
    runtime.systemstack(0x7ffed2029a70)
        /usr/lib/go/src/runtime/asm_amd64.s:314 +0xab
    runtime.(*mheap).alloc(0x83f4c0, 0x36871, 0x100000000, 0x7ffed2029ad8)
        /usr/lib/go/src/runtime/mheap.go:580 +0x73
    runtime.largeAlloc(0x6d0e2000, 0x845100, 0xc420000201)
        /usr/lib/go/src/runtime/malloc.go:774 +0x93
    runtime.mallocgc.func1()
        /usr/lib/go/src/runtime/malloc.go:669 +0x3e
    runtime.systemstack(0x83a700)
        /usr/lib/go/src/runtime/asm_amd64.s:298 +0x79
    runtime.mstart()
        /usr/lib/go/src/runtime/proc.go:1079
    
    goroutine 1 [running, locked to thread]:
    runtime.systemstack_switch()
        /usr/lib/go/src/runtime/asm_amd64.s:252 fp=0xc4200479e0 sp=0xc4200479d8
    runtime.mallocgc(0x6d0e2000, 0x0, 0x818300, 0x2a6)
        /usr/lib/go/src/runtime/malloc.go:670 +0x903 fp=0xc420047a80 sp=0xc4200479e0
    runtime.rawbyteslice(0x6d0e0a2b, 0x0, 0x0, 0x0)
        /usr/lib/go/src/runtime/string.go:307 +0xc2 fp=0xc420047ac0 sp=0xc420047a80
    runtime.stringtoslicebyte(0x0, 0xc48d1be000, 0x6d0e0a2b, 0xc420047b40, 0xc48d1be000, 0x6d0e0a2b)
        /usr/lib/go/src/runtime/string.go:145 +0xcb fp=0xc420047b08 sp=0xc420047ac0
    io.WriteString(0x7ff841e7e800, 0xc4200cc000, 0xc48d1be000, 0x6d0e0a2b, 0xc48d1be000, 0x6d0e0a2b, 0x0)
        /usr/lib/go/src/io/io.go:291 +0xe1 fp=0xc420047b60 sp=0xc420047b08
    github.com/tywkeene/autobd/index.GetChecksum(0xc42000d620, 0x27, 0x0, 0x0, 0x0, 0x0)
        /home/savior/src/go/src/github.com/tywkeene/autobd/index/index.go:45 +0x2bf fp=0xc420047c98 sp=0xc420047b60
    github.com/tywkeene/autobd/index.NewIndex(0xc42000d620, 0x27, 0x6d0e0a2b, 0xecf8927d6, 0x1c90b30b, 0x83a020, 0x1a4, 0xc420047d50)
        /home/savior/src/go/src/github.com/tywkeene/autobd/index/index.go:55 +0x16d fp=0xc420047cf0 sp=0xc420047c98
    github.com/tywkeene/autobd/index.GetIndex(0xc4200b8ba0, 0x1e, 0x3, 0x3e, 0x0)
        /home/savior/src/go/src/github.com/tywkeene/autobd/index/index.go:77 +0x2d0 fp=0xc420047de8 sp=0xc420047cf0
    github.com/tywkeene/autobd/locks.InitLocks(0xc4200b8ba0, 0x1e, 0xc4200111a4)
        /home/savior/src/go/src/github.com/tywkeene/autobd/locks/locks.go:96 +0x55 fp=0xc420047ea8 sp=0xc420047de8
    main.init.1()
        /home/savior/src/go/src/github.com/tywkeene/autobd/main.go:35 +0x153 fp=0xc420047f40 sp=0xc420047ea8
    main.init()
        /home/savior/src/go/src/github.com/tywkeene/autobd/main.go:90 +0x60 fp=0xc420047f48 sp=0xc420047f40
    runtime.main()
        /usr/lib/go/src/runtime/proc.go:172 +0x1bf fp=0xc420047fa0 sp=0xc420047f48
    runtime.goexit()
        /usr/lib/go/src/runtime/asm_amd64.s:2086 +0x1 fp=0xc420047fa8 sp=0xc420047fa0
    
    goroutine 17 [syscall, locked to thread]:
    runtime.goexit()
        /usr/lib/go/src/runtime/asm_amd64.s:2086 +0x1
    
  • Add a Gitter chat badge to README.md

    Add a Gitter chat badge to README.md

    tywkeene/autobd now has a Chat Room on Gitter

    @tywkeene has just created a chat room. You can visit it here: https://gitter.im/autobd/Lobby.

    This pull-request adds this badge to your README.md:

    Gitter

    If my aim is a little off, please let me know.

    Happy chatting.

    PS: Click here if you would prefer not to receive automatic pull-requests from Gitter in future.

  • Break up helpers.go

    Break up helpers.go

    Break up helpers.go into multiple files. This will probably be logging.go for logging functions and packing.go for tar related functions

    WriteFile() and GetQuery() will go into api.go, since it's the only file that requires them.

  • Filesystem events

    Filesystem events

    So two pretty big problems:

    1. Filesystem events aren't really tracked, so changes aren't reflected in the cache
    2. A new file could be written to, and be put into the cache, but is still being written to on the disk, so we get an invalid size and checksum

    I've started working on a filesystem monitor within autobd, but it's not working out the way I expected.

    There's no real solution to these problems, https://github.com/radovskyb/watcher doesn't report IN_CLOSE_WRITE or IN_CLOSE_NOWRITE events. This is a problem for both the cache (#52) and file semaphores (#35). Besides that, it seems this package is a bit too high level to be really useful. Gonna have to go with something a little more nuts and bolts to get things working correctly.

    I'm thinking if I could get file semaphores working via filesystem monitoring, I could just use those to control addition/removal/changes to the cache, therefor keeping the cache up to date and valid

  • .autobd directory

    .autobd directory

    So it's probably a good idea to start using an .autobd directory, to store log files (like mentioned in issue #64) and other data that's needed like the server's node list or a node's uuid

    I'm not sure if it'd be a great idea to put it directly under the node or server's root directory, since that'd expose some stuff that probably doesn't need to be exposed. But I may possibly be able to just hardcode everything to ignore that directory.

  • Implement a blockchain for versioned snapshot support

    Implement a blockchain for versioned snapshot support

    Using something like this might be good for implementing a versioned snapshot process.

    E.g:

    1. Blockchain starts on server's tarball'd directory tree
    2. Changes are made to the tree, the server regenerates the hash, and adds a new block to the chain
    3. The nodes check if there are any new blocks in the chain, downloads them and their metadata.

    The benefits of this are pretty obvious.

    • It's a lot like git, and allows you to go back in time in the case of data loss.

    • If the metadata is spread out amongst the nodes, you could still theoretically bootstrap a server from that metadata, maintaining your data's integrity

    • Each block hash is signed with a 4 digit number, so you know if something screwy is going on at a glance

    Will definitely look into this after the ongoing development process overhaul.

  • Node authorization

    Node authorization

    Right now there's no real node authorization. Of course security should be a priority. From what little research I've done something like Oauth might work pretty well. Need to look into this a little more.

Lightweight, single-binary Backup Repository client. Part of E2E Backup Architecture designed by RiotKit

Backup Maker Tiny backup client packed in a single binary. Interacts with a Backup Repository server to store files, uses GPG to secure your backups e

Apr 4, 2022
WaffleSyrup - Simple backup solution written by Go.

WaffleSyrup Simple backup solution written by Go. Usage WaffleSyrup runs in the current working directory. It will create ./tmp directory to save tarb

Apr 22, 2022
Hardening a sketchy containerized application one step at a time

Road to Secure Kubernetes Hardening a containerized application one step at a time This repository hosts a tutorial on security hardening a containeri

Jun 8, 2022
Kubernetes is an open source system for managing containerized applications across multiple hosts.
Kubernetes is an open source system for managing containerized applications across multiple hosts.

Kubernetes Kubernetes is an open source system for managing containerized applications across multiple hosts. It provides basic mechanisms for deploym

Nov 25, 2021
Kubegres is a Kubernetes operator allowing to create a cluster of PostgreSql instances and manage databases replication, failover and backup.

Kubegres is a Kubernetes operator allowing to deploy a cluster of PostgreSql pods with data replication enabled out-of-the box. It brings simplicity w

Dec 30, 2022
Dgraph Backup and Restore (cloud). Read-only mirror.

dgbrx Dgraph Backup and Restore X dgbrx is a Go commandline tool which helps to do a backup, restore or clean on a Dgraph Cloud (aka slash / managed)

Oct 28, 2021
Tape backup software optimized for large WORM data and long-term recoverability

Mixtape Backup software for tape users with lots of WORM data. Draft design License This codebase is not open-source software (or free, or "libre") at

Oct 30, 2022
Kstone is an etcd management platform, providing cluster management, monitoring, backup, inspection, data migration, visual viewing of etcd data, and intelligent diagnosis.
Kstone is an etcd management platform, providing cluster management, monitoring, backup, inspection, data migration, visual viewing of etcd data, and intelligent diagnosis.

Kstone δΈ­ζ–‡ Kstone is an etcd management platform, providing cluster management, monitoring, backup, inspection, data migration, visual viewing of etcd

Dec 27, 2022
Lxmin - Backup and Restore LXC instances from MinIO

lxmin Backup and restore LXC instances from MinIO Usage NAME: lxmin - backup a

Dec 7, 2022
πŸ›… Backup your Kubernetes Stateful Applications

Stash Stash by AppsCode is a cloud-native data backup and recovery solution for Kubernetes workloads. If you are running production workloads in Kuber

Jan 7, 2023
A library for writing backup programs in Golang

Barkup godoc.org/github.com/keighl/barkup Barkup is a library for backing things up. It provides tools for writing bare-bones backup programs in Go. T

Nov 13, 2022
Simple SFTP backup tool for files.

BakTP Simple SFTP backup tool for files. config.example.json Contains an example how to backup a database. This application can be added to crontab -e

Dec 30, 2021
MongoBackup - This is container that takes backup of MongoDB

MongoBackup This is container that takes backup of MongoDB. It is ment to be ran

Feb 15, 2022
A simple program to automatically backup a database using git. Err handling by Sentry, Reporting by Betteruptime. Made with 🩸 , πŸ˜“ & 😭

backup What is this? A Simple program to automatically backup a database using git. Err handling by Sentry, Uses heartbeats by Betteruptime Made with

Nov 4, 2022
Simple backup tool for PostgreSQL

pg_back dumps databases from PostgreSQL Description pg_back is a dump tool for PostgreSQL. The goal is to dump all or some databases with globals at o

Dec 25, 2022
Github-backup application

Github-backup application This application clone your github repository with all commits, branch, tags etc. to your local disk Dependencies This App u

Dec 26, 2022
Raspberry Pi Archlinux Automated Offline Installer with Wi-Fi. Windows, Mac and more features coming.
Raspberry Pi Archlinux Automated Offline Installer with Wi-Fi. Windows, Mac and more features coming.

Raspberry Pi Archlinux Automated Installer with Wi-Fi. Windows, Mac and more features coming. Download Go to releases page and download the zip file f

Nov 22, 2022
Automated-gke-cilium-networkpolicy-demo - Quickly provision and tear down a GKE cluster with Cilium enabled for working with Network Policy.

Automated GKE Network Policy Demo Before running the automation, make sure you have the correct variables in env-automation/group_vars/all.yaml. There

Jan 1, 2022
Rustpm - Process manager and automated updates for RustDedicated
Rustpm - Process manager and automated updates for RustDedicated

rustpm (WIP) Process manager for RustDedicated A drop in replacement for RustDed

Feb 15, 2022