Step 1: Compile FUSE support into the kernel and install s3fs
Step 2: Mount S3 bucket to a local folder on the server. To achieve this create a file /etc/passwd-s3fs and put your Access Key and Secret Access keyseparated by the colon there.
Step 3: Edit your fstab and put the following line there:
s3fs#your_bucket_name       /mnt/s3_storage       fuse    auto            0 0

This script leaves only the most recent copy of the backup in the BACKUPSDIR and 7 copies (for 7 days in a row) on the remote storage. All backups on the remote storage are encrypted with your password. Don’t forget to change it (–passphrase pwd ). Enjoy!

#!/bin/bash
#
# Back up CVS
#
CVSDIR=/home/cvs
BACKUPSDIR=/home/andrew/backups
S3DIR=/mnt/s3_storage
#
# Get current date and time
set `date +"%Y %m %d %H %M"`

# Remove any backups older than 1 days
echo "Removing backups older than 1 days..."
TO_DELETE=$(find $BACKUPSDIR -atime +1 -name "cvstree*")

if [ -z "$TO_DELETE" ]; then
    echo "No backups to delete"
else
    # remove them!
    rm -f $TO_DELETE
fi

#echo "Backing up CVS tree..."
/bin/tar -cj -C $CVSDIR --totals . > $BACKUPSDIR/cvstree_$1-$2-$3.tar.bz

echo "Encrypting the backup"
/usr/bin/gpg -c --batch --passphrase pwd $BACKUPSDIR/cvstree_$1-$2-$3.tar.bz
echo "Moving to the remote storage"
/usr/bin/mv $BACKUPSDIR/cvstree_$1-$2-$3.tar.bz.gpg $S3DIR

# Remove any backups older than 7 days on the remote storage
echo "Removing backups older than 7 days from the remote storage..."
TO_DELETE=$(find $S3DIR -mtime +7 -name "cvstree*" )

if [ -z "$TO_DELETE" ]; then
    echo "No backups to delete"
else
    # remove them!
    rm -f $TO_DELETE
fi

exit 0

I’ve been using Coremoid plasmoid since KDE 4 was available only in SVN and it provides everything I want. The plasmoid sits in the tray and displays processor usage on all cores (in case your processor has more than one core) plus the processor governor and frequency. It is useful to see whether your computer is doing something CPU intensive that you didn’t want it to do (for example there is a program hanging in memory and consuming your CPU).

The look & feel of Coremoid plasmoid

It hasn’t been actively supported since last year and the sources from kde-look.org don’t compile with latest KDE 4.2.x stable. I have made few adjustments to the code to make it compile and decided to share it with you

Download coremoid-0.3.1-andrew.tar.bz2

1. Create a backup of the root partition with tar -cvpjf --sparse --one-file-system backup_of_root.tar.bz2 /
   Note: only the contents of the root partition will be archived since –one-file-system option is specified (no dev, proc, …) WARNING! If your filesystem is mounted with extended attributes support (see /etc/fstab) and you use programs utilizing this feature (such as SELinux) you shouldn’t use tar since it won’t store any extended attributes. Use sta, pax or cpio
2. Boot with a live CD and delete the partition as well as create a new one with fdisk
3. jfs_mkfs /dev/sdaN (where N is the partition number)
4. Extract the backup with tar -xvpjf  backup_of_root.tar.bz2
5. Reboot and … a kernel panic   On my system it was “Kernel panic – not syncing: Attempted to kill init!”

After a week of kernel debugging, initrd debugging and browsing of forums I have finally found out that init script is missing character files in /dev filesystem: /dev/console and /dev/null. Without these two your Gentoo installation (and some other distributions as well) just won’t boot without telling you why!

So all you need to do to make your restored system boot again are two commands:
mknod /dev/null c 3 1
mknod /dev/console c 5 1

Happy fixing!

So I decided to go with JFS though it seemed not many use it. I’ve been using it for 6+ months and so far I haven’t got any problem. On a 100Gb partition fsck takes 10-15 minutes to run. In terms of performance – it seems to be faster than Ext3, especially with Deadline IO scheduler (vs. CFQ selected by default). Very low CPU consumption is also a big plus (vs. Reiser that will eat up to 30% of your CPU on heavy file operations). Deleting of big files (> 1Gb) takes fractions of a second.

I think JFS is much undervalued in the Linux world. The only drawback that I could find is that it seems to be impossible to shrink JFS partition under Linux. However enlarging the filesystem is really easy – all the code is built into the kernel so to enlarge your existing JFS partition (after you’ve enlarged the underlaying partition) you only need to remount it with the ‘resize’ option:

#mount -o remount,resize /home

As easy as this! So far JFS is the filesystem of my choice

You can see more info about JFS here