Шаг 1: Включить поддержку FUSE в ядро и установить s3fs
Шаг 2: Примонтировать S3 bucket к папке на сервере . Чтобы сделать это создайте файл /etc/passwd-s3fs и впишите туда одну строчку – Access Key и Secret Access key разделённые двоеточием.
Шаг 3: Редактируем fstab и вписываем туда это:
s3fs#your_bucket_name /mnt/s3_storage fuse auto 0 0

Этот скрипт оставляет самый последний бэкап в папке BACKUPSDIR на сервере и 7 копий за 7 последних дней на S3. Все бэкапы шифруются паролем, не забудте поменять его в скрипте (–passphrase pwd )!

#!/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

Я начал использовать плазмоид Coremoid с тех давних пор когда KDE 4 был доступен только из SVN. Плазмоид сидит в панели задач и показывает нагрузку на процессор по всем ядрам (если у Вас современный процессор) плюс текущий governor (алгоритм изменения частоты процессора в зависимости от нагрузки). Мне большего и не нужно. Часто бывает полезным чтобы вовремя заметить что какой-то процесс отжирает проц. Да и вообще как-то спокойней с ним – знаешь что происходит

Так выглядит Coremoid в панели задач

К сожалению исходники которые можно скачать с kde-look.org уже давно не компилируются с последними версиями KDE, включая стабильный KDE 4.2.x. Я сделал необходимые изменения в коде чтобы он компилировался с последними стабильными кедами и выкладываю исходники здесь.

Скачать coremoid-0.3.1-andrew.tar.bz2

1. 1. Создаем бэкап корневого раздела: tar -cvpjf --sparse --one-file-system backup_of_root.tar.bz2 /
   Примечание: ничего кроме файлов из корневого раздела в архиве не будет так как указана опция –one-file-system (не будет /dev, /proc, смонтированных разделов и т.д.) ВНИМАНИЕ! Если ваша файловая система монтируется с поддержкой расширенных атрибутов или вы используете SELinux – используйте pax или star вместо tar
2. Загружаемся с live CD и удалить раздел а также создать новый меньшего размера (или 2 раздела) с помощью fdisk
3. Форматируем новый корень: jfs_mkfs /dev/sdaN (N это номер раздела с Gentoo)
4. Восстановливаем файлы из бэкапа: tar -xvpjf  backup_of_root.tar.bz2
5. Перегружаемся, делаем глубокий вдох и… получаем kernel panic   В моем случае это было «Kernel panic – not syncing: Attempted to kill init!» Сообщение не говорящее ни о чем кроме того что init облажался.

После недельной отладки ядра с помощью printk а также отладки linuxrc в образе initrd оказалось что скрипту init для жизни не хватает двух файлов в /dev, а именно /dev/console и /dev/null. Причем об этом он Вам не скажет ни за что в жизни (поскольку отсутствует /dev/console)

Так что всё что Вам нужно сделать чтобы перестать рвать на себе волосы это:
mknod /dev/null c 3 1
mknod /dev/console c 5 1

Удачи!

Ext3 это старая добрая ext2, существующая еще с бородатого 1993 года, с прикрученной к ней журналом. То что файловая система изначально не разрабатывалась как отказоустойчивая (журналируемая) это уже минус. Хотя некоторые находят в этом и плюс – удалите журнал с ext3 и получите ext2 Хотя после такого трюка я бы использовать файловую систему не стал – слишком велика вероятность запороть систему при выключении питания, зависании дров и т.д. Как по мне то ext2 можно использовать разве что для boot раздела который отмонтируется как только система загрузится. И всё таки ext3 с журналом достаточно надежна – её по умолчанию предлагает большинство дистрибутивов Linux. Из недостатков стоит отметить жуткие тормоза при увеличении количества файлов в папке (при кол-ве файлов в 20000 комманда ‘ls’ занимает несколько секунд) а так же время которое занимает fsck. Упаси Вас Господь запустить fsck на разделе размером 1TB или больше (а такие разделы уже давно не редкость) – можете считать что день (или ночь) у Вас свободен А ведь в некоторых дистрибутивах fsck запускается автоматически через 30 mount’ов. Поверьте, я знаю что это такое

ReiserFS – интересная файловая система Интересная в первую очередь тем что её отец и создатель – Hans Reiser, признан виновным в убийстве первой степени (убил свою жену). Естественно об активном развитии ReiserFS пока, к сожалению, не может быть и речи. Что касается технических показателей – ReiserFS показывает очень хорошую производительность при большом количестве мелких файлов. Однако нагрузка на процессор у ReiserFS при этом существенная – намного больше чем у ext3, XFS и тем более JFS. Кроме того система не очень стабильна при отключении питания и сбоях в железе – многие будут с этим спорить однако случаев потери данных с ReiserFS достаточно много. 3-я версия файловой системы включена в ядро и достаточно стабильна, в то время как 4-я версия всё еще в разработке и повидимому разработка её так и не завершится. Лично я использовал бы ReiserFS как файловую систему для раздела хранящего кэш прокси сервера. Для этой цели она подходит идеально.

XFS – достойный выбор. Очень хорошо показывает себя при работе с большими файлами (а значит больше всего подходит для разделов хранящих видео:)). Однако стабильность в случае отключения питания или сбоев в железе далеко не на высоте. Если погуглить на эту тему то можно найти достаточно подтверждений этому. Нагрузка на проц так же не высока. Общая производительность чуть лучше чем у ext3. По набору всевозможных фич – одна из первых. Однако и недостатков тоже хватает – кроме вышеупомянутой нестабильности при сбоях так же нет комманды undelete, файловая система не может быть уменьшена, создание директорий занимает намного большее время чем в других ФС.

JFS – файловая система разработанная IBM еще в древние времена для OS/2, а в последствии для AIX

• полностью 64-битная (в отличии от ext3)
• размер места под i-nod’ы (дескрипторы файлов) является динамическим – тоесть нет ограничения на кол-во файлов (опять же в отличии от ext3)
• внутреннее представление файлов в директории позволяет эффективно управлять как директориями с небольшим кол-вом файлов так и директориями с огромным кол-вом файлов
• поддержка как внутреннего (находящегося на том же разделе что и сама ФС) так и внешнего (находящегося на другом устройстве) журнала
• разработана для больших систем – гарантируется одинаковая производительность как на мелких файлах так и файлах размером до 4-х петабайт
• fsck работает с космической скоростью – намного быстрее ext3 и ReiserFS
• Расчитана на работу на многопроцессорном железе – код оптимизирован для работы на системах с 4-мя ядрами и более
• Нагрузка на процессор при файловых операциях минимальна – меньше чем у ext3 и намного меньше чем у ReiserFS

Есть конечно же и недостатки – невозможность уменьшить раздел (необходимо создавать новый) и относительно малое количество пользователей Linux которые её себе установили. А вот увеличить раздел – просто секундное дело. Весь код уже в ядре – всё что нужно это перемонтировать систему с флагом resize!

#mount -o remount,resize /home

Производительность JFS выше чем у ext3 и xfs, особенно с Deadline шедулером (вместо CFQ включенного в ядро по-умолчанию).

Я установил JFS еще в прошлом году и прошло уже больше 6 месяцев – ни единой проблемы. Для меня JFS остается наиболее технологичной, производительной и надежной файловой системы – именно поэтому я доверил ей корневой раздел Gentoo