Представьте, что ваш дата-центр (или боевой сервер) сегодня упал. Просто взял и упал. Как показывает практика, готовы к этому далеко не все:

• 93% компаний, которые теряли свой ЦОД на 10 и более дней из-за катастрофы, стали банкротами в течение года _{(National Archives & Records Administration in Washington)}
• Каждую неделю в США выходит из строя 140 000 жестких дисков _{(Mozy Online Backup)}
• У 75% компаний нет решений для аварийного восстановления _{(Forrester Research, Inc.)}
• 34% компаний не тестируют резервные копии.
• 77% тех, кто тестируют, обнаруживали нечитаемые накопители в своих библиотеках.

В предыдущих постах (раз и два) я писал про организационные меры, которые ускорят и облегчат восстановление ИТ-систем и связанных с ними процессов компании при чрезвычайной ситуации.



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

Состоялся релиз версии 1.0 beta свободной программы GMVault, которая предназначена для бэкапа почтового архива Gmail на локальном диске и восстановления данных в случае сбоя на Gmail. Поддерживается синхронизация по заданному интервалу, криптографическая защита, несколько gmail-аккаунтов.

GMVault — хороший вариант для тех, кто не в полной мере доверяет надёжности облачного хранилища Gmail, но не готов отказаться от удобного веб-интерфейса. Shell/batch-клиент доступен для Linux, Mac OSX и Windows.

В топике — основные действия по обеспечению непрерывности бизнеса, которые дают базовый результат. Эти действия помогут избежать катастрофы, выполнить аварийное восстановление и выйти из ситуации с минимальными потерями.

Напоминаю, руководство внедрением — задача очень ценимая руководством, и, почти всегда в России, ведущая к карьерному росту.

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

Знакомая ситуация?

Есть такая штука – непрерывность бизнеcа. Эта сфера уже достаточно развита и подразумевает, что ваш бизнес может продолжить работу без происшествий даже после попадания метеорита в дата-центр или офис.

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

Ответ на вопрос, чем заняться в международный день бэкапа (который отмечается 31 марта, то есть сегодня), напрашивается сам собой — конечно бэкапом своих данных!

Посвятите этот день мыслям (раз уж сегодня суббота — ограничимся мыслями, а дела можно сделать в понедельник) об установке и настройке систем резервного копирования, утвердите SLA по восстановлению информации в случае аварий, передайте свежие резервные копии по сети в соседний офис на случай пожара. А если вы до сих пор не делаете бэкап — тогда мы идем к вам самое время его сделать!

Под катом полезные советы и приятная игрушка к дню бэкапа

Это продолженеие статьи о помехоустойчивом кодировании, которая очень долго лежала в черновиках. В прошлой части нет ничего интересного с практической точки зрения — лишь общие сведения о том, зачем это нужно, где применяется и т.п. В данной части будут рассматриваться некоторые (самые простые) коды для обнаружения и/или исправления ошибок. Итак, поехали.

Вступление.

Прежде всего стоит сказать, что такое Код Хэмминга и для чего он, собственно, нужен. На Википедии даётся следующее определение:

Коды Хэмминга — наиболее известные и, вероятно, первые из самоконтролирующихся и самокорректирующихся кодов. Построены они применительно к двоичной системе счисления.

Другими словами, это алгоритм, который позволяет закодировать какое-либо информационное сообщение определённым образом и после передачи (например по сети) определить появилась ли какая-то ошибка в этом сообщении (к примеру из-за помех) и, при возможности, восстановить это сообщение. Сегодня, я опишу самый простой алгоритм Хемминга, который может исправлять лишь одну ошибку.

Всё началось с простой задачи: скачать по 100-мегабитной сети большой объём данных с помощью rsync. Возник вопрос, можно ли ускорить этот процесс. Утилита top показала, что на сервере-источнике шифрование занимает не более 10 процентов процессора, поэтому было решено что можно попробовать сжатие данных. Тогда мне было неясно, будет ли хватать производительности процессора для упаковки данных с необходимой скоростью, поэтому была выставлена самая маленькая степень сжатия, а именно использовался флаг --compress-level=1 для rsync. Оказалось, что загрузка процессора не превысила 65%, то есть производительности процессора хватило, при этом скорость скачивания данных несколько повысилась.

После этого возник вопрос о анализе применимости распространённых программ сжатия
для передачи данных по сети.

В ответ на топик «В комнате с белым потолком».

Введение

В топике было предложено эффективное решение для устранения некоторых проблем эникеем. Дополним и означим их списком:

• Последствия работы вирусов, а, иногда, и последствия борьбы с вирусами приводят к состоянию системы, в котором она «недолечена» или «недочищена»;
• Слабое железо или жадность не позволяет использовать серьезные антивирусные пакеты;
• Ошибки пользователей или специализированных программ приводят к неменьшему ущербу, чем вредоносные программы (случай, когда у программы сложно забрать рута, а работает она не очень оптимально);
• Система подвержена естественному (для нее) «замусориванию» со временем;
• Ошибки администратора системы может приводить к серьезным последствиям (напр., неудачная попытка обновиться);
• Отсутствие автоматизированной системы для резервного копирования (напр., есть Acronis, но не сетевой);
• и прочие ...