© 2004-2007 Tadeusz Pietraszek
Just a neat one liner:
perl -ne ‘if (/^diff .* ([^\s]+)$/ || eof()) { print “$file $plus $minus\n”; $file = $1; $plus = 0; $minus = 0;} /^+/ && $plus++; /^-/ && $minus–;’
This is mental hot-line, if you are obsessive compulsive, press 1 repeatedly. If you are co-dependent ask someone to press 2 for you. If you have multiple personalities press 3,4, 5 and 6. If you are paranoid, we know who you are, we will call you………
“Hello, Welcome to the Psychiatric Hotline.” If you are obsessive-compulsive, please press 1 repeatedly. If you are co-dependent, please ask someone to press 2. If you have multiple personalities, please press 3, 4, 5 and 6. If you are paranoid-delusional, we know who you are and what you want. Just stay on the line until we can trace the call. If you are schizophrenic, listen carefully and a little voice will tell you which number to press. If you are manic-depressive, it doesn’t matter which number you press. No one will answer
Something, which might be a nice postfix/opengroupware/cyrus-imap/… replacement. All in one. A nice idea, but I feel somewhat resitant… Hula Project – Hula
For our server we needed a “push type” backup, supporting incremental backups, transport over SSH and encrypted repositories. After evaluating a dozen of open-source backup tools, I chose duplicity. Although it doesn’t have too many bells and whistles, it does its job pretty well.
The way I run it is:
export PASSPHRASE=''
duplicity $@ --encrypt-key <keyid> --include-globbing-filelist /root/backup/dobackup.list --exclude '**' / ssh://<where>/<dir> && duplicity --remove-older-than 3D --force ssh://<where>/<dir>
For the encryption it uses a PGP key, which you need to generate (root needs to generate, unless you want to use a special key) and backup separately. The last one is quite important, as when your disk breaks down, the last thing you want to test is how difficult to break your 2048bit gpg key is 
Other than that we dump the content of two our databases (not trusting file-level backups of “live” databases):
mysqldump -A -C > $BACKUPDIR/mysql-alldatabases.dump
su postgres pg_dumpall > $BACKUPDIR/pgsql-alldatabases.dump
We also generate a list of Debian packages:
dpkg --get-selections | diff - $BACKUPDIR/dpkg-selections.log > /dev/null || dpkg --get-selections > $BACKUPDIR/dpkg-selections.log
And autocommit and add entries to our SVN repository (a neat perl one-liner):
SVNAUTOCOMMIT="/etc"
NEWFILES=svn status $SVNAUTOCOMMIT | perl -ne '/\?\s*(.*)/ && print "$1 "'
if [ -n "$NEWFILES" ]; then
svn add $NEWFILES
fi
svn commit -m "Autocommit from a backup script" $SVNAUTOCOMMIT
(0) Dumping the database: pg_dump mssd -F c -f file.dumppsql -U mssd -h 127.0.0.1 -O -x
And restoring it: pg_restore -d mssd file.dumppsql -U mssd -h 127.0.0.1 -O -x -O – do not change the ownership -x – do not restore ACLs
Yes, it happened to us. Even if the network connection was fast, the initial connection was too slow. The culprit turned out to be a faulty DNS server of our provider—probably SSH does a rev DNS lookup on connecting or something like this.
After running our server as a recursive DNS server and changing the entries in resonv.conf to localhost, the problem disappeared.
Generating sitemaps using a sitemap generator from Google. 1. Create the XML file with a sitemap, in particular the tags <site base_url=”http://tadek.pietraszek.org/” store_into=”webpage/tadekp/sitemap.xml.gz” verbose=”1″ > <directory path=”webpage/tadekp” url=”http://tadek.pietraszek.org” /> 2. Run the generator: ./sitemap_gen.py –config=tadek.pietraszek.org.xml