sophisticated Backups mit Rsync Part II

Version 3.1
Features:

  • Logs werden nun gzip komprimiert
  • wöchentliche Backups aus der vorherigen Woche werden tar.gz komprimiert

 

#!/bin/sh

# Philipp's backup-scripte version 3.1

ROOT=`pwd`
BACKDIR=$ROOT/backup

D=`eval date +%Y-%m-%d`
W=`eval date +%Y-%W`
w=`eval date +%w`
LATEST="latest"
EXCLUDE=$ROOT/exclude.txt
SOURCES=$ROOT/sources.txt

LOG=$ROOT/log/$D.log

# Array mit allen ben‚‚tigten Verzeichnissen und Ordnern
folders=( $ROOT/log )
files=( $EXCLUDE $SOURCES $LOG)

for folder in ${folders[@]}; do
    if [ ! -d $folder  ] ; then mkdir -p $folder; fi
done

for file in ${files[@]}; do
    if [ ! -f $file  ] ; then touch $file; fi
done

log () {
    if [  -z "$1" ] ; then echo "" > $LOG ; fi
    echo $1
    echo $1 >> $LOG    
}

# needs Hostname
gzipLastWeekly (){
    log "=================================================================="
    log "compress...";
    echo $1
    ROOT=`pwd`
    L_BACKDIR="$ROOT/backup/$1/weekly"; 
    if [ -d $L_BACKDIR ] ; then    
        NUM=${#L_BACKDIR}+1;
        L_LATEST=`ls -al $L_BACKDIR/latest`
        L_FOLDER="${L_LATEST#*-> }";
        L_FILE="${L_LATEST#*-> }";
        L_FILENAME="${L_FILE:$NUM:7}";
        log "L_BACKDIR $L_BACKDIR";
        #log "L_LATEST $L_LATEST";
        log "L_FOLDER $L_FOLDER";
        log "L_FILE $L_FILE";
        log "L_FILENAME $L_FILENAME";
        log "=================================================================="          
        if [ -d $L_FOLDER ] ; then
            if [ $L_FILENAME != "$W" ]; then
                log "compress  $L_FOLDER";
                cd $L_BACKDIR
                tar -cvf - $L_FILENAME/ | gzip > $L_FILENAME.tar.gz  | tee -a $LOG
                cd $ROOT
                rm -R $L_FOLDER
                log "MD5: "
                log "=================================================================="
                md5 $L_BACKDIR/$L_FILENAME.gz -out $LOG;
                log "=================================================================="
            fi
        fi    
    fi
    log "...done";
    log "==================================================================" 
}

# Ab hier gehts dann richtig los :-)

log

log "STARTING BACKUP..."
log "date: $D"

#stopping start time
#TIME0= expr `date +%s`;

# backup following sources
for SOURCE in `cat $SOURCES`; do
    log ""
    log "=================================================================="
    log "====== backup: $SOURCE "
    if [ ! -d $BACKDIR/$SOURCE/daily/$D  ] ; then mkdir -p $BACKDIR/$SOURCE/daily/$D; fi    
    if [ ! -f $BACKDIR/$SOURCE/src-root.txt  ] ; then touch $BACKDIR/$SOURCE/src-root.txt; fi    
    if [ ! -f $BACKDIR/$SOURCE/src-folders.txt  ] ; then touch $BACKDIR/$SOURCE/src-folders.txt; fi      
    #Logindaten lesen
    LOGINDATA=`cat $BACKDIR/$SOURCE/src-root.txt`
    if [ ! "$LOGINDATA" = "" ]; then
        log "====== benutze $LOGINDATA" 
        log "=================================================================="
        log ""
        for FOLDER in `cat $BACKDIR/$SOURCE/src-folders.txt`; do
            log "backup up... $FOLDER"
            mkdir -p $BACKDIR/$SOURCE/daily/$D/$FOLDER
            ### wenn schon latest-day vorhanden, dann sichere nur ‚nderungen
            if [ -d $BACKDIR/$SOURCE/daily/$LATEST  ] ; then 
		        log "using latest: $BACKDIR/$SOURCE/daily/$LATEST"
                rsync -zrva $OLD --exclude-from=$EXCLUDE --link-dest=$BACKDIR/$SOURCE/daily/$LATEST/$FOLDER  $LOGINDATA/$FOLDER/ $BACKDIR/$SOURCE/daily/$D/$FOLDER | tee -a $LOG
            else
                rsync -zrva $OLD --exclude-from=$EXCLUDE $LOGINDATA/$FOLDER/ $BACKDIR/$SOURCE/daily/$D/$FOLDER | tee -a $LOG
            fi   	
        done

        ### setze latest von altem Stand auf aktuelles Backup
        if [ -d $BACKDIR/$SOURCE/daily/$D ] ; then
            log "Daily: deleting ln last daily latest: $BACKDIR/$SOURCE/daily/$LATEST"
            if [ -d $BACKDIR/$SOURCE/daily/$LATEST ] ; then rm $BACKDIR/$SOURCE/daily/$LATEST; fi
            log "Daily: updating ln daily latest: $BACKDIR/$SOURCE/daily/$LATEST"
            ln -s $BACKDIR/$SOURCE/daily/$D $BACKDIR/$SOURCE/daily/$LATEST | tee -a $LOG     
            log "Daily: deleting ln last daily latest: $BACKDIR/$SOURCE/$LATEST"
            if [ -d $BACKDIR/$SOURCE/$LATEST ] ; then rm $BACKDIR/$SOURCE/$LATEST; fi
            log "Daily: updating ln daily latest: $BACKDIR/$SOURCE//$LATEST"
            ln -s $BACKDIR/$SOURCE/daily/$D $BACKDIR/$SOURCE/$LATEST | tee -a $LOG     
        fi

        ### setze latest-global von altem Stand auf aktuelles Backup
        log "Daily: deleting ln last global latest: $BACKDIR/$SOURCE/$LATEST"
        if [ -d $BACKDIR/$SOURCE/$LATEST ] ; then 
            rm $BACKDIR/$SOURCE/$LATEST;
        fi            
        log "Daily: updating ln global latest"
        ln -s $BACKDIR/$SOURCE/daily/$D $BACKDIR/$SOURCE/$LATEST | tee -a $LOG 

        ## wenn ende der Woche, dann erstelle Snapshot der Woche
        if [ "$w" = "0" ]; then
            log "Weekly: create week-backup for $W"
            for FOLDER in `cat $BACKDIR/$SOURCE/src-folders.txt`; do
                mkdir -p $BACKDIR/$SOURCE/weekly/$W/$FOLDER
                rsync -zrva $OLD --exclude-from=$EXCLUDE $BACKDIR/$SOURCE/daily/$D/$FOLDER/ $BACKDIR/$SOURCE/weekly/$W/$FOLDER | tee -a $LOG
            done

            ### komprimiere letztes week Backup
            log "==================================================================" 
            log "Weekly: compressing last weekly latest"
            gzipLastWeekly $SOURCE

            ### setze latest-day von altem Stand auf aktuelles Backup
            log "Weekly: deleting ln last daily latest: $BACKDIR/$SOURCE/daily/$LATEST"
            if [ -d $BACKDIR/$SOURCE/daily/$LATEST ] ; then 
                rm $BACKDIR/$SOURCE/daily/$LATEST;
            fi

            ### loesche alte Backups
            log "Weekly: delete all daily folders"
            rm -R $BACKDIR/$SOURCE/daily/*

            log "Weekly: updating ln daily latest: $BACKDIR/$SOURCE/daily/$LATEST"
            ln -s $BACKDIR/$SOURCE/weekly/$W $BACKDIR/$SOURCE/daily/$LATEST | tee -a $LOG            

            ### setze latest-week von altem Stand auf aktuelles Backup
            log "Weekly: deleting ln last weekly latest: $BACKDIR/$SOURCE/weekly/$LATEST"
            if [ -d $BACKDIR/$SOURCE/weekly/$LATEST ] ; then 
                rm $BACKDIR/$SOURCE/weekly/$LATEST;
            fi

            log "Weekly: updating ln weekly latest"
            ln -s $BACKDIR/$SOURCE/weekly/$W $BACKDIR/$SOURCE/weekly/$LATEST | tee -a $LOG 

            ### setze latest-global von altem Stand auf aktuelles Backup
            log "Weekly: deleting ln last global latest: $BACKDIR/$SOURCE/$LATEST"
            if [ -d $BACKDIR/$SOURCE/$LATEST ] ; then 
                rm $BACKDIR/$SOURCE/$LATEST;
            fi            
            log "Weekly: updating ln global latest"
            ln -s $BACKDIR/$SOURCE/weekly/$W $BACKDIR/$SOURCE/$LATEST | tee -a $LOG 
        fi
    fi
done

#stopping end time
#TIME1= expr `date +%s`;
#ERG = expr `$TIME1 - $TIME0`;

log "=================================================================="
log "DONE"
#log "using $ERG seconds"
log "=================================================================="

gzip $LOG -f

 

quick note: subversion

find all .svn folders:

find . -type d -name .svn
./.svn
./sourceA/.svn
./sourceB/.svn
./sourceB/module/.svn
./sourceC/.svn

delete all .svn folders:

rm -rf `find . -type d -name .svn`

 

via: http://www.anyexample.com/linux_bsd/bash/recursively_delete__svn_directories.xml

Das Problem mit der Abstraktion der Arbeit

Aus aktuellem Anlass möchte ich mich hier einem Thema widmen, welches möglicherweise jeden betrifft. Es geht um die Tatsache, dass man um sich herum Projekte und Arbeit sucht, welche sich über die Zeit ansammelt und mit der Zeit liegen bleibt. Es gibt viele Theorien und Methoden, wie man dieser Situation begegnen soll. Meistens geht es um – mehr oder weniger – hippe Methoden mit noch trendigeren Namen (z.B. GettingThingsDone). Sucht man nach dem Thema Arbeitsmethoden oder Zeitmanagement, finden sich ganze Bücherregale mit Titeln, unterschiedlicher Ausrichtung.
Dennoch habe ich mir persönlich die Frage gestellt, wieso man viele Dinge anfängt, nach einiger Zeit zurückblickt und zu dem Ergebnis kommt, dass man doch zum aktuellen Zeitpunkt weit von einem (dem) gesteckten Ziel entfernt ist, welches man eigentlich hat erreichen wollen. Ich spreche hier nicht von den typischen Kandidaten wie “Ich sollte mal wieder den Keller aufräumen”, oder auch “Irgendwie sollte ich mal wieder die Steuern machen :-(“. Es geht mir hier um die vielen kleineren und größeren Projekte, die man sich (und hin und wieder auch zusammen anderen Mitmenschen) vor langer Zeit gestellt hat und die trotz vieler Möglichkeiten daniederliegen und meist über das erste Planungsstadium nicht hinweg gekommen sind.
Ich möchte nachfolgend ein paar Punkte nenne, die ich an mir selber (als quasi Betroffener), hin und wieder aber auch bei anderen (als unbeteiligter Beobachter), bemerkt habe:

  1. Titelgebend und meiner Meinung nach einer der seltsamsten Gründe – Abstrahierung des Probemes:
    Ich habe lange Zeit überlegt, ob Abstrahierung überhaupt der richtige Begriff ist. Letztendlich ist damit gemeint, dass man ab einem gewissen Punkt erkennt, dass man das gesetzte Ziel rein theoretisch sicher und zu 100% erreichen kann. Dies mag zum einen Daraus resultieren, dass man in dem Arbeitsumfeld schon einiges an Erfahrung gesammelt hat, zum anderen auch daran, dass man im Beruf oder in anderen Situationen schon schwierigere/komplexere Dinge gelöst hat. So werden viele Aufgaben vor sich her geschoben und im Team werden simple, unerfreuliche, langweilige, aber notwendige Aufgaben an Unerfahrende Helfer abgeschoben, weil das eigene Genie sich für höheres berufen fühlt. Während man selber also nur mit dem Kopf die Dinge löst und selber fest der Meinung ist, dass die Verwirklichung der eigenen Ideen nur noch Detailfragen aufwerfen wird, wird man hinterher von dem langsamen Fortschritt und einer fehlerhaften Basis überrascht werden.
  2. Das “Ich mache lieber alles selbst, weil es sonst falsch ist, oder zu lange dauert” – Problem.
  3. “Keine Zeit – das mache ich dann mal, wenn ich (Frei-)Zeit habe” / “sobald X eintritt, mache ich das mal”
  4. “Lasst uns die Wikipedia nachbauen”
  5. “Das sieht so simpel aus – das kann ich auch”

instant jruby & derby environment für eine RoR Anwendung

Als angestammter Java-Entwickler geht es mir oftmals schwer von der Hand, einer Ruby on Rails (RoR) Anwendung mit relativ wenig Aufwand eine brauchbare Laufzeitumgebung zu bieten.
Normalerweise sollte das OS (MacOS 10.5.6) alles Brauchbare bieten. So ist oftmals eine Rails-Version installiert und auch das (standardmäßig genutzte) SQlite 3 ist vorhanden.
Dennoch sind es oftmals Plugins (spezielle Rails Version / spezielle gems), welche einen zusätzlichen Aufwand benötigen.
Nicht zu vergessen, dass RoR nicht auf allen Systemen vorinstalliert ist und dementsprechend ein interessierter Entwicklung von einem Out-of-the-Box Erlebnis weit entfernt ist.
Sehen wir den Tatsachen ins Auge… die Wahrscheinlichkeit eine installierte JVM vorzufinden ist (noch?) deutlich höher, als eine Lauffähige Ruby-Installation.
Was liegt also näher, als die benötigte Umgebung auf Java fußen zu lassen.
Hierzu werden verwendet:

  • jRuby in Version 1.1.5 (http://jruby.codehaus.org)
  • Derby-DB in Version 10.4.2.0 (http://db.apache.org/derby)
  • weiterhin wird eine installierte JVM (>1.5) vorrausgesetzt

 

Alles weitere wird mit Hilfe von shell-Scripten bewerkstelligt. Wobei momentan nur Unix-Scripte benutzt werden. Eine Portierung auf Windows sollte aber nur eine Sache von Minuten sein.
Es liegt eine RoR-Anwendung in einem Entwicklungs-Status vor. Diese wurde bisher in einem Netbeans-Enviroment mit einer SQlite-DB betrieben.
Das Verzeichnis ist folgendermaßen aufgebaut:

ROOT
|
|- microblog (dies ist unsere RoR-Anwendung)
|
|- derby (derby-installtion - es werden jeweils das bin und lib Verzeichnis benötigt)
| |-bin
| |-lib
|
|- jruby (jruby-installtion - es werden jeweils das bin und lib Verzeichnis benötigt)
| |-bin
| |-lib

Das Hauptproblem besteht darin, dass alle benötigten gems in das entsprechende Unterverzeichnis installiert werden müssen.
Weiterhin muss die Derby-DB mit dem entsprechenden Rake-Task auf mit der aktuellen Schema-Datei instanziiert werden.
Zuletzt sollen die vorhandenen User-Daten in die Derby-DB eingefügt werden.

  1. Anpassen der database.yml
    Wir nutzen weiterhin eine jdbc-Connection. Allerdings ändert sich der Treiber auf den der Derby-DB:
    database.yml

    development:
    adapter: jdbc
    driver: org.apache.derby.jdbc.ClientDriver
    url: jdbc:derby://localhost/microblog_development;create=true
    encoding: utf8
    pool: 5
    username: microblog
    password: microblog
    host: localhost
  2. Export der alten DB-Daten:
    Wir benutzen hierzu das Tool sqlitebrowser (http://sqlitebrowser.sourceforge.net) und erzeugen uns so einen SQL-Dump der alten SQLite-DB. Wir benutzen hierbei nur die SQL-Inserts für den User-Import. Diese speichern wir in die Datei:
    microblog/db/microblog.sql
  3. Für den Import erstellen wir einen Rake-Task:
    microblog/lib/tasks/sql-import.rake

    namespace :microblog do
    desc 'Import old SQL Data'
    task :sqlimport => :environment do
    dbConn = ActiveRecord::Base.establish_connection :development
    sql = File.open("db/microblog.sql").read
    sql.split(';').each do |sql_statement|
    dbConn.connection.execute(sql_statement)
    end
    puts "imported user data '#{Time.now}' "
    end
    end
  4. Erstellen des Setup-Scriptes:
    Folgende Schritte sind notwendig:

    1. Setzen aller benötiger Verzeichnisse
    2. installieren aller benötigter gems
    3. Starten des Derby-DB-Servers
    4. Rake db:migrate
    5. import der alten Daten
    6. Beenden des Derby-DB-Servers

    Das Script sieht wie folgt aus:
    jruby-setup.sh

    #!/bin/sh
    BASE_DIR=`pwd`
    CP=".:$BASE_DIR/jruby/lib/*:$BASE_DIR/derby/lib/derbyclient.jar"
    JAVA_OPTS="-Djdbc.drivers=org.apache.derby.jdbc.EmbeddedDriver"
    JRUBY="$BASE_DIR/jruby/bin/jruby"
    DERBY_HOME=`cd derby && pwd`
    export DERBY_HOME=$DERBY_HOME
    cd $BASE_DIR
    echo "setting up jgems..."
    $BASE_DIR/jruby/bin/jruby $BASE_DIR/jruby/bin/jgem update --system
    $BASE_DIR/jruby/bin/jruby $BASE_DIR/jruby/bin/jgem install jruby-openssl --no-rdoc --no-ri
    $BASE_DIR/jruby/bin/jruby $BASE_DIR/jruby/bin/jgem install -v=2.2.2 rails --no-rdoc --no-ri
    $BASE_DIR/jruby/bin/jruby $BASE_DIR/jruby/bin/jgem install activerecord-jdbc-adapter activerecord-jdbcderby-adapter --no-rdoc --no-ri
    echo "starting derby..."
    $BASE_DIR/derby/bin/startNetworkServer &
    echo "setting up derby..."
    cd microblog
    $BASE_DIR/jruby/bin/jruby $BASE_DIR/jruby/bin/rake db:migrate
    $BASE_DIR/jruby/bin/jruby $BASE_DIR/jruby/bin/rake microblog:sqlimport
    cd $BASE_DIR
    echo "stopping derby..."
    $BASE_DIR/derby/bin/stopNetworkServer &

    Es ist zu erwähnen, dass es notwendig ist, jeweils auf die entsprechende jRuby-Installation zu verweisen.
    Weiterhin benötigt jRuby den entsprechenden derbyClientDriver, welcher in die (von jRuby später verwendete) JAVA_OPTS-Variabel eingetragen wird.
    Ebenfalls musst der Classpath soweit angepasst werden, dass sowohl jRuby, als auch Derby über die notwendigen Bibliotheken verfügen.
    Als letztes ist noch erwähnenswert, dass die beiden Rake-Tasks jeweils aus dem App-Verzeichnis ausgeführt werden.

  5. Das Start-Script.
    Letzendlich sind auch zum eigentlichen Betrieb des Servers Anpassungen notwendig, da auch hier die jRuby-Instanz mit den verwendeten gems benutzt werden sollen.
    Das Script sieht wie folgt aus:
    run.sh

    #!/bin/sh
    BASE_DIR=`pwd`
    CP=".:$BASE_DIR/jruby/lib/*:$BASE_DIR/derby/lib/derbyclient.jar"
    JAVA_OPTS="-Djdbc.drivers=org.apache.derby.jdbc.EmbeddedDriver"
    JRUBY="$BASE_DIR/jruby/bin/jruby"
    export BASE_DIR=$BASE_DIR
    export JRUBY=$JRUBY
    DERBY_HOME=`cd derby && pwd`
    export DERBY_HOME=$DERBY_HOME
    cd $BASE_DIR
    echo "starting derby..."
    $BASE_DIR/derby/bin/startNetworkServer &
    echo "setting up derby..."
    cd microblog
    $BASE_DIR/jruby/bin/jruby $BASE_DIR/jruby/bin/rake db:migrate
    echo "starting microblog"
    $BASE_DIR/jruby/bin/jruby $BASE_DIR/microblog/script/server
    echo "stopping derby..."
    $BASE_DIR/derby/bin/stopNetworkServer &

    Es entspricht also einer abgespeckten Variante des Setup-Scriptes. Hierbei wird auch immer ein db:migrate aufgerufen, für den Fall, dass sich die DB-Struktur in der Zwischenzeit geändert haben sollte.

  6. Auslieferung ;-).
    Derby und jRuby belegen knapp 80 MB sodass es notwendig ist, die Dateigröße für den Transport zu verringern.
    Zuallererst sollten die benötigten gems am besten immer online bezogen werden, sodass man hier ein paar MB sparen kann.
    Weiterhin benutzen wir Jar um die vorhandenen Dateien auf ein 13 MB-Archiv zu packen.
    Die veränderten Scripte sehen wie folgt aus:
    Zuerst das Script, welches die vorhandenen Dateien packt:
    pack.sh

    #!/bin/sh
    find . -name '*.DS_Store' -type f -delete
    jar -cvf statusQ-runtime.jar derby/ jruby/ run.sh pack.sh microblog/db/microblog.sql microblog/lib/tasks/sql-import.rake
    rm -R jruby
    rm -R derby
    rm run.sh
    rm microblog/db/microblog.sql
    rm microblog/lib/tasks/sql-import.rake
    rm pack.sh

    Und nun das geänderte jruby-setup.sh Script, welches vor dem eigentlichen Setup noch für das Entpacken aller Dateien verantwortlich ist:
    jruby-setup.sh

    #!/bin/sh
    jar -xvf statusQ-runtime.jar
    rm -R META-INF
    chmod +x run.sh
    chmod +x setup.sh
    chmod +x pack.sh
    chmod +x jruby/bin/jruby
    chmod +x derby/bin/startNetworkServer
    chmod +x derby/bin/stopNetworkServer
    BASE_DIR=`pwd`
    CP=".:$BASE_DIR/jruby/lib/*:$BASE_DIR/derby/lib/derbyclient.jar"
    JAVA_OPTS="-Djdbc.drivers=org.apache.derby.jdbc.EmbeddedDriver"
    JRUBY="$BASE_DIR/jruby/bin/jruby"
    DERBY_HOME=`cd derby && pwd`
    export DERBY_HOME=$DERBY_HOME
    cd $BASE_DIR
    echo "setting up jgems..."
    $BASE_DIR/jruby/bin/jruby $BASE_DIR/jruby/bin/jgem update --system
    $BASE_DIR/jruby/bin/jruby $BASE_DIR/jruby/bin/jgem install jruby-openssl --no-rdoc --no-ri
    $BASE_DIR/jruby/bin/jruby $BASE_DIR/jruby/bin/jgem install -v=2.2.2 rails --no-rdoc --no-ri
    $BASE_DIR/jruby/bin/jruby $BASE_DIR/jruby/bin/jgem install activerecord-jdbc-adapter activerecord-jdbcderby-adapter --no-rdoc --no-ri
    echo "starting derby..."
    $BASE_DIR/derby/bin/startNetworkServer &
    echo "setting up derby..."
    cd microblog
    $BASE_DIR/jruby/bin/jruby $BASE_DIR/jruby/bin/rake db:migrate
    $BASE_DIR/jruby/bin/jruby $BASE_DIR/jruby/bin/rake microblog:sqlimport
    cd $BASE_DIR
    echo "stopping derby..."
    $BASE_DIR/derby/bin/stopNetworkServer &

Als nächstes sollte die Scripte auf Windows portiert werden.
Weiterhin wäre es interessant, die Derby/jRuby Binaries jeweils direkt online zu beziehen.