I can’t remember how many times I needed this line recently. I also could never remember it (hm… do you see a pattern here?). So here it is for future reference:
find . -name "*.php" -print | xargs sed -i '.backup' 's/foo/bar/g'
It’s pretty much self explanatory. If I could only make it stick in my brain.
Today when I woke up my MacBook greeted me with very unpleasant alert:
The network backup disk does not support the required AFP features.
It turnes out that during the upgrade to Lion Apple used their newest set of commands that were not compatible with stable netatalk package in Ubuntu.
To get my network storage to work again I had to upgrade to the latest netatalk 2.2.beta4.
First download all needed files from Ubuntu’s repositories
wget http://launchpadlibrarian.net/73070555/netatalk_2.2~beta4-1_amd64.deb
wget http://launchpadlibrarian.net/74978789/libgcrypt11_1.5.0-1_amd64.deb
wget http://launchpadlibrarian.net/75629511/multiarch-support_2.13-9ubuntu3_amd64.deb
wget http://launchpadlibrarian.net/72120162/libgpg-error0_1.10-0.3ubuntu1_amd64.deb
wget http://launchpadlibrarian.net/74358655/libdb5.1_5.1.25-11_amd64.deb
Then install it:
dpkg -i multiarch-support_2.13-9ubuntu3_amd64.deb
dpkg -i libgpg-error0_1.10-0.3ubuntu1_amd64.deb
dpkg -i libgcrypt11_1.5.0-1_amd64.deb
dpkg -i libdb5.1_5.1.25-11_amd64.deb
dpkg -i netatalk_2.2~beta4-1_amd64.deb
I’ve chosen to keep old version of configuration files, the only notable difference was that now afpd.conf lists -tcp -noddp options as defaults. I added them to my list. Quick restart of netatalk daemon and voila – Time Machine works again.
I am a fan of Apple’s Time Machine backup system since it’s introduction. And I’ve always wanted to implement something similar on my server. Since I have that nice spacious NAS disk right now space stopped to be a problem (at least for a little while). Little googling shows that rsync has a special option allowing me to implement Time Machine’s method of incremental backups using rsync. In that method rsync uses existing backup as additional source for comparing files and if file did not change since last backup has been done a hard link is being created to this file instead of copying. This way I should end up with daily directories of files but only new/changed files will be eating up disk space.
Let’s give it a try. My backup script looks like this:
#!/bin/bash
date=`date “+%Y-%m-%d”`#Mysql dump
for i in /var/lib/mysql/*/; do
dbname=`basename $i`
/usr/bin/mysqldump -u root -pyourpasshere $dbname | gzip -c > /home/mysql/$dbname-$date.sql.gz
done#Rsync
rsync -arpvogDtSWz \
-e “ssh ” \
–delete \
–link-dest=../mysql-current \
./mysql/ \
root@nas:/path/to/backups/mysql-$date#Moving links up one day
ssh root@nas \
“cd /path/to/backups/ && rm -f mysql-current && ln -s mysql-$date mysql-current”
The script dumps all dbs to a directory on hard drive, then rsyncs this directory with dated folder on a nas server using mysql-current (which is a symlink to latest daily backup) as additional sorce of files (–link-dest parameter).
I’ve run the script and then checked out the results:
root@nas# du -sh mysql-*
92M mysql-2011-05-16
19M mysql-2011-05-17
512 mysql-current
Looks like indeed the disk usage of the newer directory reflects only today’s copies of dbs. To confirm that hard links work as they should I deleted one file in the oldest directory. And now:
root@nas# du -sh mysql-*
86M mysql-2011-05-16
25M mysql-2011-05-17
512 mysql-current
the older directory size dropped but the newer directory size went up as the same file was hard linked there too and now that directory represents the only physical copy of the file on disk.
That’s exactly what I wanted to achieve.
Now to fully implement Time Machine mechanisms I need to make a script that will calculate the amount of free space needed on backup drive and delete the oldest backups accordingly until there is enough space available (as you see above simply deleting one file may not free up any hard drive space) to mve on with the transfer.
If you want to use SUN’s java version with rxtx on any debian derivative system you’d be surprised to discover that jre can’t find rxtx libraries if you installed them using librxtx-java package. It’s because SUN does not adhere to debian naming and placing policies and looks for libraries in wrong place. Quick fix:
cd /usr/lib/jvm/java-6-sun/jre/lib/
cp /usr/share/java/RXTXcomm.jar ./
cd i386
cp /usr/lib/jni/lib* ./
That will make those libs available to SUN’s java and everything should work from now on.
Recently our collection of storage hard drives started to look a little bit too big. Yet we had several drives with a lot of free space fragmented between them but neither of them has enough free space itself to make you me comfortable. Trying to do something with it I decided to start looking for a solution that would allow me to aggregate those drives and their space providing me with one big logical partition. Oh, and having some kind of security would be nice too.
Browsing the internet I have found nice solution called Drobo. That’s exactly what I want to have. Nice, compact solution providing scalable space at the same time protecting data in RAID like manner. There is only one problem with Drobo (and it’s not the price). Drobo uses proprietary software and from several cases described over the internet it seems like when it goes bad, it goes really bad really quick, usually loosing most of the info stored. And then the only chance you have is to send the box with all drives to the company itself and pray they can restore something for you. That effectively deletes this device from my list.
But browsing further I stumbled upon ZFS. This seems to be ‘the best file system and last you’ll ever need’. It provides ability to create software RAID systems which are supposed to be secure and fast. So home brewing my own NFS server seems to be the best option. Even more appealing as I’ll be able to use the same machine to run our HVAC system.
First step was to get all needed hardware.
So far total spent: $173. Not bad I would say.
