Очередные пакости

[vitus_wagner]

В домашнем компьютере сдох терабайтный винт. Вот так вот прям посреди 75-дневного аптайма взял и сдох.
Сначала ошибка чтения такого-то блока, а потом читаться перестает все и совсем.

После выключения и включения компьютера несколько минут работает, а потом опять бздям...

Правда часть тех данных, которые не были забэкаплены, за эти несколько минут спасти удалось.

Но в общем положение крайне неприятное. Потому что как бэкапить лежавшие на том диске архивы, которые пополняются нерегулярно и непредсказуемо, я как следует не придумал. Поэтому забэкаплено оказалось не все.
А то что забекаплено, нужно будет очень долго выкапывать из нескольких коробок с DVD.
Ну не присполсоблены кролики для лазанья, а DVD для бэкапа терабайтных объемов.

Самое обидное что это случилось как раз тогда, когда в Москве цены на жесткие диски существенно подскочили из-за таиландских наводнений.

Еще обидно, что второй месяц собираюсь наладить репликацию видимых извне данных на vds-ку, но вот так и не успел. Полярный зверь пришел раньше.

Поэтому извините, если картинки не грузятся. Пострадали в основном именно они.

Upd Посоветуйте, кстати, какой диск покупать. Заглянув на сайт oldi.ru я что-то там вижу все зеленое. Seagate Barracuda Green (5900rpm) и WD Caviar Green (хрен мы скажем вам сколько у нас оборотов). При этом разница в цене между терабайтными и двухтерабайтными моделями 10-20%.
Материнская плата у меня на чипсете Nvidia nForce 430 (MCP61), это вроде как SATA II.

Comments

[shaplov.livejournal.com]

Говорят, для того чтобы получить сколь либо разумную надежность SATA дисков, следует пользоваться зеркальными рейдами. При этом обязательно на дисках разных производителей... (У Ку был случай, когда диски однопартийники стоящие в рейде сдохли одни за другим в течении считанных дней, или даже дня)

[vitus_wagner]

Ну не уверен что мне нужна "разумная надежность" в таком понимании. Есть подозрение что разумную надежность на сколь угодно разнообразном наборе дисков, засунутых в один корпус и подключенных к одному блоку питания, все равно не обеспечишь.

Мне же в общем-то не требуется uninterruptable сервис.

Поэтому репликация между географически разнесенными локациями, пожалуй, лучше. Вот только беда в том, что те репликации, которые я налаживал 5 лет назад, похоже уже сдохли.

[dzz]

Про uninterruptable никто не говорит - достаточно возможности сохранения всех данных при единичном отказе. RAID1 или 5 даёт достаточно времени, чтобы при вылете диска съездить в магазин за заменой.

[dzz]

Как вариант - облачные хранилища вроде dropbox-а. Синхронизация автоматическая, но о безопасности придётся заботиться дополнительно.

[avryabov.livejournal.com]

У меня дома софтверный raid1 даже на windows поднят. А уж на линуксе с его приятными raid возможностями не поднять raid... ну это уж совсем не любить эту машинку.
Я держу в raid диски одного производителя. в нормальном режиме они разом не дохли не разу (хотя один раз навернулись пара в raid 5 от перегрева в серверной).
За последние 10 лет разные raid меня спасали от потери данных и времени по перенастройки системы минимум 5 раз. А скорее все 20.
Всё уже не упомню.

[dzz]

Достаточно из разных партий. И hot spare - для домашнего использования они может и излишни, но в продуктиве обычно есть.

[dzz]

Витус, ну сделайте уже себе RAID, хотя бы 5 уровня. Стоит относительно недорого, но оправдывает себя при первом же фатальном сбое ;)

[vitus_wagner]

RAID это
1. дорого. Потому что нужны минимум три диска меньшей емкости вместо одного большого. А 2TB стоит всего на 10-20% дороже чем 1TB. Соотвественно RAID 5 2Гб емкости из трех дисков будет стоить вдвое дороже одного диска, не считая затрат на смену блока питания, обеспечение охлаждения и т.д.
2. шумно.
3. Требует дисциплины мониторинга сравнимой с требуемой для нормлаьного резервного копирования дисциплиной,.
4. Рассеивает в комнату намного больше тепла.

В общем, когда в продаже появятся абсолютно бесшумные SSD гиг этак на 250 по цене порядка 1000 рублей и с максимальным потреблением 5W, я рассмотрю вопрос RAID.

[dzz]

Мне кажется, что:

1. Некритично при современных ценниках на HDD. Можно взять 3 диска меньшего объёма для RAID5 за те же деньги, что два "неприкрытых".

2 и 4. Решается правильным выбором дисков.

3. Простейший cron-скрипт с нотификацией по почте. С резервным копированием несравнимо потому, что резервирует постоянно, а не по расписанию.

Меня, во всяком случае, RAID при домашнем использовании спасал уже дважды, в самой старой RAID-группе за 5 лет заменены 2 диска из 3, данные на месте.

[ddeennaaddaa.livejournal.com]

>3. Требует дисциплины мониторинга сравнимой с требуемой для нормлаьного резервного копирования дисциплиной

Не соглашусь.
Вся "дисциплина мониторинга" начинается и заканчивается (как уже справедливо отметили тут) разовой акцией настройки отсылки варнинга по желаемому евенту.

>В общем, когда в продаже появятся абсолютно бесшумные SSD гиг этак на 250 по цене порядка 1000 рублей и с максимальным потреблением 5W, я рассмотрю вопрос RAID

Износ ресурса SSD в RAID-массивах происходит более-менее равномерно, что приводит к залповым вылетам этих носителей. Энтерпрайзные SLC-носители несколько смягчают ситуацию, но не устраняют проблему полностью (что, собственно, и послужило толчком к введению RAID-вендорами в свои контроллеры функционала SSD Guard).

Вообще же скорость работы SSD достигается организацией флеш-групп внутри носителя в страйп (RAID 0). Полагаю, что внезапный выход из строя произвольной флеш-группы и приводит к ситуациям, когда SSD резко умирает (не в ro по исчерпанию лимита перезаписи, а именно с концом).

С уважением,
De Nada.

P.S. В качестве оффлайн-хранилищ я использую
http://www.raidsonic.de/en/products/soho-raid.php?we_objectID=6863
и
http://www.raidsonic.de/en/products/details.php?we_objectID=7059

- внешние USB/eSATA-коробушки с собственным "зеркалированием" (думаю, что внутри что-то простенькое класса недорогих Промайзов, на которых строят дешёвые 50-баксовые PCI-ные недорейды). Два года (на моделях USB2/eSATA) - полёт нормальный. Кста, сейчас сую в них Сигейты на 5900 - много оборотов не нужно, а за данные спокойнее.
Ну или не только у РаидСоника есть такой товар - сейчас многие вендоры таким балуются.

P.P.S RAID 5 сейчас если и не зло, то уж и не такое "добро", как было ранее, в эпоху "сказёвых гиговников" (или "гиговых сказёвников"). Я предпочитаю R-10 (там, где не хватает R-1)...

[avryabov.livejournal.com]

не хотя бы 5 уровня а хотя бы 1-го.
и софтверный. Очень просто. Очень надежно. Практически без потери производительности. Из расходников - 1 HDD. Все.
RAID 5 - гораздо более требовательная вещь.

[dzz]

> и софтверный

разумеется, софтверный

> RAID 5 - гораздо более требовательная вещь

Угу, всего-то +1 диск (при росте полезного объёма в 2 раза) и чуть-чуть нагрузки на CPU (c) :)

[dimm-w.livejournal.com]

Вот такой Hitachi: http://www.oldi.ru/catalog/element/0157121/
ИМХО, Hitachi очень надежные!

[p_govorun]

Зелёные WD брать нельзя. Они останавливают шпиндель после нескольких минут idle и это невыключаемо.

[vitus_wagner]

А если там torrent-клиент, оно когда-нибудь станет idle (ну кроме случая отключения машины от интернета)

[p_govorun]

"Использование торрент-клиента для защиты диска от износа". :-)

[belpartizan.blogspot.com]

Это легко лечиться через hdparm -B 254 -M 254

[tzirechnoy.livejournal.com]

Чтобы слить данные -- могу посоветовать его охладить. В смысле -- вынуть из корпуса, отнести от батареи, поставить под вентилятор. В некоторых случаях дажэ бывает, что потом им можно пользоваться.

PS Кстати, я сейчас устроил себе бэкап файлопомойки при помощи git+sshfs (ну, +lvm).

lvm -- поскольку это нормально используемая файлопомойка, а git очень удивляется, если в процэссе записи файла в репозиторий он внезапно меняется.

set -e
set -x
PATH=/sbin:/usr/sbin:/bin:/usr/bin

bdate="`date +'%Y-%m-%d-%H-%M'`"
# What to backup
ORIGVOLUME=/dev/tempvideo/v2
BACKUP_DIR=YYYYYY
# Snapshot, and it's mountpoint
SNAPVOLUME=/dev/tempvideo/snap-v2-$bdate
MPATH=/mnt/mednm-back/snapshots/v2-$bdate

# Backup destination, it's mountpoint
TARGET="backer@XXXXXXX.com:/mnt/sda11/backup/YYYYYY"
GIT_DIR=/mnt/XXXXXX-back/YYYYYY
COMMIT_MESSAGE="Backup of YYYYYY on host .... to XXXXXX at $bdate"

# The following ia a script like 
##!/bin/sh
#exec ssh -i /root/.ssh/id_dsa_backer_XXXXXX "$@"
# to use special identity for remote login.
SSH_CMD="ssh_command=/root/ssh_backer_XXXXXX"

mount |grep "^$TARGET on $GIT_DIR type" ||\
sshfs -o allow_other,cache_timeout=3600,reconnect,"$SSH_CMD" "$TARGET" "$GIT_DIR"
sync
sync
lvcreate -L 400M -s "$ORIGVOLUME" -n "$SNAPVOLUME"
mkdir $MPATH
mount -o nouuid "$SNAPVOLUME" "$MPATH"
git  --git-dir="$GIT_DIR"  --work-tree="$MPATH/$BACKUP_DIR" add -v -A -N "$MPATH/$BACKUP_DIR"
git  --git-dir="$GIT_DIR"  --work-tree="$MPATH/$BACKUP_DIR" commit --allow-empty -m "$COMMIT_MESSAGE" -a
sync
sync
umount "$MPATH"

set +e
lvremove -f "$SNAPVOLUME"
while [ $? -eq "5" ] ; do lvremove -f "$SNAPVOLUME" ; done

Правда, во-первых, это пока не особо оттэстировано. (пинки принимаются с интересом). И вообще, я для поста добавил некоторое количество переменных из тех, что были прописаны внутрь кода, плюс комментарии, и никак пока это не тэстировал.

Ну, и осторожнее с переменной SNAPVOLUME -- если по непониманию впишэте в неё какую-то из существующих, то есть шанс внезапно её лишыться. Это должно быть новое имя, обязательно. Для того там дата и впилена.

Замечу, что просто git commit -a не подцэпит новые файлы, а git add без -N запихает полный список в потребные для git commit -- и git commit будет каждый файл пытаться опять записать, для чего попытается прочесть все объекты в своей базе. Но git add -N/git commit -a работает вроде нормально.

Ещё замечу, что, кажэтся, у git ограничение в 4G на размер файла. Я в этом не 100% уверен, но вроде в index большэ не пишэтся.

В остальном -- клёвая база для архивов. Несложный формат, и куча народу делает/смотрит на код глазами. Отрезать только последние несколько месяцэв, кстати, тожэ можно -- есть такая вещь как git clone --depth. Там сказано, что на получившэеся нельзя будет опять натравить git clone -- но это неправда, если опять использовать git clone --depth, чтобы глубина клона не захватывал большэ, чем есть в репозитории -- то вполне можно.

PS И да, можно сказать, что git вообще не для этого предназначен, и это всё плохо, и авторы рассчиывали на маленький текст, который пишэт один человек на репозиторий -- а не на стагигабайтные помойки с дампами баз и вордовыми/CADовскими документами.
На это я замечу, что спецыфичные утилиты для архивирования и резервного копирования тех файлопомоек (от tar/dump до бакулы) -- они все хужэ, и обычно сильно хужэ (ну, не для всех вариантов использования, но в моём случае -- точно).

Так почему бы не использовать для этой цэли инструмент, который подходит лучшэ.

[filin]

В моем случае лучшим вариантом из существующих мне показался rsnapshot. Почти ничего лишнего. Принцип - бэкап rsync'ом делается обратно-инкрементальным посредством предварительного cp -al (если cp не гнутый, rsnapshot эту команду эмулирует сам). Отрезать последние несколько - дешевле не придумаешь, просто удаляются лишние директории, и гарантированно никаких сбоев, связанных с неполной базой истории.

Сам rsnapshot при этом - довольно тупой перловый скрипт. Если cp гарантированно гнутый, можно даже вместо него написать скрипт на sh, идея выше, но мне пока и так неплохо. Мне кажется, что git в данном случае - немножко через ж.

[tzirechnoy.livejournal.com]

А, ещё PS: на винде и вообще на FAT/NTFS после git init надо грохнуть hooks/pre-commit в git. Чтобы не запускался.

[filin]

Вот в вопросе "куда бэкапить" я уже давно сошелся к варианту "на внешний винчестер". В моем случае не шибко обширных архивов и нетбука как основной машины это USB. Бэкап rsync'ом (из-под rsnapshot, но я все подумываю ту же функциональность написать под себя еще проще, хотя казалось бы, куда еще?), обратно-инкрементальный (перед rsync'ом там делается cp -al предыдущего бэкапа). На бэкапном винте шифрованная fs, но это из разряда паранойи, а не то чтобы очень по делу (винт все же периодически переезжает с места на место) - и кстати, там же на первом разделе live-система с соответствующими пакетами (надо, кстати, будет ее обновить). Бэкапный винт подключается, естественно, вручную, обычно на ночь, потому что вместе с двумя серверами это удовольствие на 3-5 часов. Дальше запустил скрипт и пошел спать.

[vitus_wagner]

При этом у тебя какой-нибудь zero-клик используется? В смысле чтобы вот воткнулся и раскрутился внеший винчестер - начинаем бэкапить? Или лучше без него.

Ни в коем случае не WD Caviar Green.

[dinozavr]

Страшная вещь - безумно тяжелая, очень сильно греющаяся (рекордсмен по нагреву за последние 20 лет у меня), и, главное, невероятно, реально невероятно тормозная. Раза в 3 медленнее (по юзер опыту, тесты не делал) чем все, что в принципе ожидаешь от САТА.

Существенно медленней IDE.

Не рекомендую. Купил, и был вынужден положить на полку - переквалифицировал в хранилище.

Да, и шум у него тоже рекордный.

Оборотов, видимо, 5400. Раньше писали.

Феерически негодное железо.
Пробовал и под windows и под Linux.

Re: Ни в коем случае не WD Caviar Green.

[shadowfoto]

>переквалифицировал в хранилище.

а это оно и есть. насыпать в него 100500 данных и убрать на полочку. для иного не предназначено и не приспособлено. в отличие от Seagate/Maxtor LP (на 5900RPM которые)

[henry_flower]

вот этим диск обработать: http://www.grc.com/spinrite.htm пробовали? (есть в торентах, если вдруг)

у меня как-то, по всем признакам, издох 120 гб хитачи. отот спинрайт его мучил часов 10, но вымучил--хитачи я еще пользовал месяц, пока не купил новый wd.