Bashup is written in heavy Bash syntax and has few dependencies to external programs. You should image it as a scripting library for backups as it allows to call different backup methods and is more a framework than a fully integrated solution. The power of this is the ability to be free in the creation of a backup process while still using easy methods.

The following is a fairly easy setup of bashup for backing up some directories over ssh. You see that we only source the bashup library here, setup some variables and call the bashup method then which executes the backup.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28

#!/bin/bash
# source bashup lob
. bashup_lib.sh
 
# set setup source - we want to backup a tree
SOURCE=tree
# set source dirs
TREE_DIRECTORIES="$HOME/PDF $HOME/ogg"
# setup filter for compression
FILTER=bzip2
 
# set destination - we want to ssh
DESTINATION=ssh_file
# set ssh host, you could be clever
# and setup access in .ssh/config
SSH_HOST=host.name.tld
# set remote file name
FILE=file.name.bz2
 
# we want two types of logging
USE_REPORTERS="console log"
 
# set the log file names
COMBINED_LOG=combined.log
ERROR_LOG=error.log
 
# call bashup
bashup

I admit this example won’t win a Noble award but if you are busy with setting up backups on very different servers you might like the idea of a scripting environment which only needs bash. Imagine your power when digging deeper into the bashup lib and calling the special methods directly while piping output and more. This is possible of course.

In the next weeks I’ll show you how to use backup rotation (yes, also over ssh, ftp and other methods), mysql/postresql/oracle/subversion backup, nagios feedback integration and more.

If you like to test and tell me what you think or even want to provide patches, feel free to checkout bashup:

svn co https://bashup.svn.sourceforge.net/svnroot/bashup bashup

1. The sender

The sender has to call netcat in server mode and pipe content into it. The next line tells tar to build a tarball and write it to standard output which is redirected via a pipe to netcat. Netcat is told to start in server mode (-l), listen on port 7878 (-p 7878) and shutdown itself after waiting 10 seconds after having seen an end of file in standard input (-q 10):

$ tar c directory | nc -q 10 -l -p 7878

2. The receiver

The receiver has to call netcat and tell him to connect to the remote machine and the correct port and redirects the standard output to a file. For convenience he also sets a timeout parameter (-w 10):

$ nc -w 10 remotehost 7878 > nameoftar.tar

That’s all. You just setup a very fast file transfer. For testing purposes use localhost. Please note that on the receiver side you are completely free to choose a file name for the .tar file. If you use something like gzip or bzip2 compression you should choose something like .tar.gz or .tar.bz2 of course.

Thanks to mnemonik pointing this out.

Feel free to add your file transfer quick hack here.