Резервное копирование и восстановление

Надежное хранение данных

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

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

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

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

Здесь уместно заметить, что системному администратору или проектировщику системы следует полагаться только на проверенные решения. Следующие несколько абзацев предназначены тем, кто планирует эксплуатировать Solaris на платформе x86, поскольку платформа Sun SPARC представляет собой более чем проверенное решение, за качество которого единственный его производитель, Sun Microsystems, ручается головой. Случаев жалоб на фирменное оборудование Sun в России мне слышать не приходилось. Коллеги из московского представительства: поправьте меня, если я не прав!

Берегись плохого оборудования и глупости – версия x86

Итак, если перед вами стоит задача проектирования системы на платформе x86, постарайтесь учесть опыт (в том числе и печальный!) автора этих строк.

Во-первых, следует использовать ту аппаратуру, которая точно находится в HCL Solaris вашей версии.

Во-вторых, следует всегда заботиться о совместимости аппаратуры и стараться эксплуатировать ее в щадящем режиме; например, не следует использовать мощность блока питания на 100%, не следует полагаться на те значения, которые написаны на наклейке этого блока питания – вполне возможно, что измерения покажут, что его фактическая мощность меньше в полтора раза.

В-третьих, жесткий диск должен быть произведен на заводе с хорошей репутацией; справьтесь у хорошо знакомого вам продавца и нескольких независимых экспертов, особенно занимающихся ремонтом жестких дисков, какие жесткие диски в данный момент считаются самыми надежными. Часто бывает, что какой-нибудь производитель выпускает отличные SCSI-диски на одном заводе и отвратительные IDE-диски – на другом под той же маркой. Избегайте привлекательных знакомых товарных знаков самих по себе – всегда интересуйтесь качеством именно того товара, который покупаете.

В-четвертых, НИКОГДА не пробуйте самые последние новинки в том оборудовании, которое должно выполнять какие-то жизненно важные функции. Если душа просит экспериментов, проведите их на том компьютере, крах которого никому не принесет слез или потерянных данных.

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

Вокруг компьютеров не должно быть пыльно, корпуса следует располагать так, чтобы к ним всегда был удобный доступ, в том числе и для уборки. Провода имеет смысл наматывать в специальные органайзеры – такие бывают встроены в сетевые фильтры APC или продаются отдельно для 19-дюймовых стоек.

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

Вот неполный список причин, по которым изначально исправные компьютеры чаще всего выходят из строя из-за недостатков планирования или плохого учета всех факторов при монтаже системы:

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

Все события, которые перечислены в этом списке, происходили в разных организациях на моих глазах в последние несколько лет, и будет странно, если по прочтении этой книги все читатели побегут перепланировать свои электросети и компьютерные системы. Гром не грянет – сами понимате что. Зато теперь вы предупреждены о последствиях. Если вы отвечаете за компьютерную систему крупного банка и все проблемы из списка давно предусмотрены и предотвращены – можно расслабиться. Должно быть, что-нибудь все равно произойдет, но хотя бы не из этого перечня.

Планируйте замену оборудования заранее! Сервер на платформе x86 не должен работать как часы в течение десятилетий; такое оборудование потребует полной замены через пять лет, более того, уже через год-два оно потеряет в цене половину. Если вы заботитесь не только о надежности работы системы, но и об экономической эффективности, следует планировать замену оборудования с продажей старого не реже, чем раз в два года.

Аппаратные средства хранения данных

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

Для долговременного хранения и создания архивов по-прежнему применяют ленточные накопители (кассеты DLT могут содержать до 70 Гбайт данных, а SDLT – до 160 Гб, при аппаратном сжатии производитель – компания Hewlett Packard обещает емкость 320 Гб), оптические диски (CD-R, CD-RW, DVD), Jaz- и ZIP-накопители. В некоторых случаях используют дискеты.

Для повышения надежности систем хранения, основанных на жестких дисках, применяют RAID-массивы – аппаратуру, которая позволяет сохранять данные с той или иной степень избыточности. Solaris поддерживает аппаратуру RAID, за подробностями описания RAID-массивов можно обратиться к фирменной документации производителей (StorEdge и многие другие) или к доступным источникам в Интернете.

С точки зрения операционной системы, RAID-массив представляет собой просто один жесткий диск. То, что фактически такой массив состоит из многих (обычно пяти-семи) дисков и может обеспечивать возможность замены дисков "на лету", без выключения или перенастройки оборудования, скрыто от операционной системы и гарантируется аппаратурой самого RAID-массива. Такие массивы обычно присоединяются к шине SCSI и стоят достаточно дорого по сравнению с обычными дисками.

Программные средства хранения с избыточностью

Для экономии средств вы можете отказаться от приобретения аппаратуры RAID. Solaris – начиная с самых ранних версий этой системы – предоставляет возможность организовать полноценный RAID-массив программно, с использованием нескольких жестких дисков и программы Solstice Disksuite. Эта программа дает возможность выполнять зеркалирование (RAID уровня 1), так же как и расслоение с избыточностью (запись блоков данных и блоков четности на разные диски – RAID уровня 5). Файловая система ZFS, которая поддерживается во всех версиях Solaris, начиная с Solaris 10, поддерживает не только программное зеркалирование и программный RAID-5, но и RAID с двойной избыточностью (см. команду zpool create raidz2 dev1 dev2 dev3 dev4 ).

В Solaris начиная с версии 8 Disksuite включен в состав системы, ранее его надо было устанавливать как отдельный пакет. Этот пакет – не единственный, позволяющий реализовать программный RAID в Solaris, но он пользуется популярностью у администраторов Solaris.

Solstice DiskSuite был переименован в Solaris Volume Manager при переходе от Solaris 8 к Solaris 9 и стал еще более тесно интегрирован в систему. Вызвать графическую оболочку Solaris Volume Manager можно из Solaris Management Console. Самостоятельно она не вызывается.

Для создания зеркала или программного массива RAID 5 в SVM используйте команду metainit. Для проверки – metastat.

Подробное описание работы с SVM можно найти, например, по адресу http://sysunconfig.net/unixtips/soft-partitions.html.

Кроме SVM есть еще широко известный продукт Veritas Volume Manager (от компании Veritas Software), c ним можно познакомиться по адресу www.veritas.com.

Пользуйтесь современным инструментарием – если у вас Solaris 10, то ZFS поможет в надежном хранении данных!

Резервное копирование и восстановление файловых систем ZFS

Справка по командам

Создание снимка файловой системы test/opt ; 19Mar08 – уникальное имя снимка:

zfs snapshot test/opt@19Mar08

Передача снимка на ленту (можно указать другое устройство, файл или перенаправить снимок на вход другой программе – в том числе для передачи по сети):

zfs send test/opt@19Mar08 > /dev/rmt

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

zfs receive test/opt@19Mar08 < /dev/rmt

Откат файловой системы до состояния, в котором она была на момент снимка:

zfs rollback test/opt@19Mar08

Перенос пулов ZFS между компьютерами

Если возникла необходимость переноса дисковой подсистемы целиком из одного компьютера в другой (например, при выходе из строя материнской платы или другого компонента, который не удается быстро заменить на аналогичный), то пул ZFS можно перенести даже без сохранения порядка подключения устройств. Благодаря тому, что каждое устройство в пуле хранит информацию о своих "соседях", как бы вы ни подключили диски, пул ZFS будет работоспособен на новом компьютере. Таким образом можно переносить не только пулы, собранные из дисков, но и пулы, собранные из накопителей USB-флэш.

Для импорта пула ZFS в другую систему следует дать команду zpool import. Для вывода из работы пула в исправно работающей системе с целью его переноса в другоую систему, следует применить команду zpool export.

Так как файловая система ZFS спроектирована для корректной работы независимо от того, какой порядок бит в байте принят в архитектуре компьютера, допустим перенос пулов ZFS между компьютерами с разным порядком бит (например, между x86 и SPARC).