Как я FreeBSD 6.0 резервно копировал


Введение

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

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


Исходные данные

Имеем локальную корпоративную сеть со следующими параметрами:

  1. Домен под управлением MS Windows 2000 Server, домен носит название MyDomain.local.

  2. Контроллер домена нас интересовать не будет.

  3. Файловый сервер, содержащий всевозможные общие папки для пользователей сети, под управлением FreeBSD 6.0 (об установке системы именно на этот сервер мы говорили здесь – http://sysadmin.su/index.php?option=com_content&task=blogcategory&id=32&Itemid=81). Сервер вписан в домен, разумеется. Полное имя сервера – FreeBSD.MyDomain.local.

  4. Ещё один сервер под управлением MS Windows 2003 Server, на котором, кроме всего прочего, решено хранить архивные копии. Полное имя сервера – BackServer.MyDomain.local.

  5. Локальная сеть подключена к Интернету.

Задача

Обеспечит ежедневное резервное копирование всех общих ресурсов на этом сервере. Само собой, копирование должно проходить автоматически. Кроме того, резервные копии необходимо хранить на стороннем сервере, каковым в данном случае является сервер BackServer. Разумеется, при работе на Windows-серверах мы работаем с правами администратора домена, а на FreeBSD-сервере – с правами root.


Вариант №1

Самый простой вариант – поручить резервное копирование серверу под управлением MS Windows. Для этого, как известно, в комплект поставки Windows входит утилита Microsoft Backup. С её помощью можно архивировать не только локальные данные компьютера, но и любые сетевые папки (равно как и состояние локальной системы).

По предложенному варианту в программе Microsoft Backup на сервере BackServer создаётся задание. Расписание – ежедневно (куда-нибудь на ночные часы, чтобы днём сеть не нагружать лишним). В качестве архивируемых данных указать «Выбранные файлы и папки» и выбрать нужные сетевые ресурсы на сервере FreeBSD. Ну а в качестве носителя, на который будет производиться архивирование, выбрать (точнее, создать) локальный файл на сервере BackServer. При этом, разумеется, задание должно исполняться от имени администратора домена (это тоже настраивается при установке расписания). Кроме того, у учётной записи администратора домена должен быть доступ ко всем архивируемым папкам хотя бы для чтения. Впрочем, покажите мне ресурс сети, к которому нет доступа у системного администратора...

Основное преимущество этого способа состоит в том, что он привычен для тех, кто работает с ОС MS Windows. В данном случае архивирование сетевых ресурсов сервера под управлением FreeBSD ничем не отличается от архивирования любых других ресурсов. Кроме того, программа Microsoft Backup позволяет выбрать режим архивирования. В частности, инкрементное архивирование (иначе оно называется добавочным) позволяет сохранять в архиве все версии каждого файла, что может оказаться весьма полезным – необходимость вернуться к сто раз переделанной версии какого-нибудь договора всегда может возникнуть. Но кроме вполне очевидных преимуществ имеются и свои недостатки.

Открыв созданный Microsoft Backup архив вы обнаружите, что в нём содержится несколько архивных наборов – по одному на каждый запуск (разумеется, если используется инкрементное архивирование). И все наборы имеют свой размер – от нуля и до максимальной величины архива. Но почему от нуля?

Инкрементное копирование выполняется ежедневно, но архивируются при этом не все файлы источника, а только те, которые были изменены со времени последнего архивирования или вновь созданы и в архиве отсутствуют. Что это значит? К примеру, 1 февраля вы работали с каким-то документом и сохранили его. Соответственно, в ночь с 1 на 2 февраля при автоматическом архивировании этот файл будет включён в архив – он же изменился. Соответственно, он будет присутствовать в наборе, созданном в этот раз. Но пусть, далее, вы в течение месяца этого файла больше не касались. Это означает, что во всех последующих наборах этот файл будет отсутствовать. Просто потому, что со времени последнего архивирования он не менялся и архивированию не подлежит.

Теперь предположим, что вы этот файл удалили (или он сам посыпался – не важно). Необходимо его восстановить. Открываем наше хранилище резервных копий и видим... Что видим? Видим в нём тридцать наборов – по одному на каждый день. И только в одном из них есть наш файл – в самом первом, ибо в остальные он не включался по причине своей неизменности. Стало быть, и восстановить его мы сможем только из первого набора. Но этого мало...

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

А теперь предположим, что речь идёт не об одном файле, а о целом проекте, который состоит из ста файлов – рисунки, чертежи, какие-то документы, таблицы, да мало ли, что там может быть ещё. Совершенно очевидно, что с разными файлами проекта работали в разные дни. Соответственно, они будут присутствовать в разных архивных наборах. К примеру, 1 февраля скинули в проект какие-то схемы в рисунках, 5 февраля делали по схемам чертежи, 7 февраля заполняли документацию, 10 февраля переделывали два неудавшихся чертежа, 17 февраля вносили изменения в документацию и т.д. Потом проект случайно удалили и его надо восстановить.

Если в этом случае мы возьмём набор от 1 февраля, то в нём не будет чертежей – они на тот момент отсутствовали. В наборе от 7 февраля два чертежа будут неверны – ведь на тот момент их ещё не исправили. В наборе от 17 февраля не будет рисунков со схемами – они не изменялись и в этот набор не включены (впрочем, как и чертежи). Иными словами, нам придётся восстанавливать наш проект из пяти разных наборов. А теперь представим, что мы не помним, когда и с какой частью проекта мы последний раз работали (ведь только так и бывает – пользователь таких вещей никогда не помнит). Ну и не забудем, что архив ведётся уже три месяца и в нём – девяносто наборов. Вам уже стало страшно?


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

Дело в том, что каждый сервер должен обслуживать себя самостоятельно – таковы уж религиозные требования. В самом деле, тот же BackServer может быть занят не только хранением резервных копий, но и выполнять ещё с десяток ролей. К тому же, ему нужно время (и мощности) для архивирования себя самого. В общем, хотелось бы производить резервное копирование средствами FreeBSD. Кроме всего прочего, так эстетичнее.


Вариант №2

Резервирование сервера FreeBSD можно поручить самому серверу FreeBSD, используя утилиты и ПО, имеющиеся в комплекте поставки FreeBSD 6.0. Головной утилитой для резервного копирования в составе FreeBSD 6.0 является bacula. На самом деле, в коллекции портов FreeBSD 6.0 имеется огромное количество утилит для резервного копирования. Для получения их списка достаточно перейти в каталог /usr/ports и ввести команду:

make search key=«backup» | more

Список и в самом деле огромен:

Port: mtf-0.2.1. Info: A Unix reader for the Microsoft Tape Format used by NT Backup

Port: rvm-1.0. Info: An archive manager that uses rsync to manage backups

Port: usogres-0.8.1_1. Info: Real-time backup utility for PostgreSQL

Port: multisync-backup-0.82_4. Info: Multisync backup plugin

Port: vmsbackup-4.1.1. Info: Reads VMS BACKUP tapes

Port: afbackup-3.3.5_3. Info: AF's backup system

Port: afbackup-client-3.3.5_3. Info: AF's backup system

Port: afbackup-server-3.3.5_3. Info: AF's backup system

Port: lxdvdrip-1.51_2. Info: Command Line Tool to make a copy from a Video DVD

Port: streamdvd-0.4. Info: A fast tool to backup Video DVDs 'on the fly'

Port: pilot-link-0.11.8_4,1. Info: PalmPilot communications utilities (backup/restore/install.)

Port: afio-2.5. Info: Archiver & backup program w/ builtin compression

Port: bacula-client-1.38.5_1. Info: The network backup solution (client)

Port: bacula-server-1.38.5_1. Info: The network backup solution (server)

Port: be_agent-5.046. Info: VERITAS Backup Exec (tm) UNIX Agent

Port: bksh-1.7. Info: Backup-only shell

Port: boxbackup-0.09. Info: An open source, completely automatic on-line backup system for UNIX

Port: cdbkup-1.0_1. Info: Simple but full-featured backup/restore perl scripts (uses gnu tar)

Port: cpbk-2.0. Info: Backup Copy programm

Port: dar-2.2.2_1. Info: A full featured command-line backup tool, aimed for disks

Port: dirvish-1.2.1. Info: Network backup system based off of rsync

Port: duplicity-0.4.2. Info: Untrusted backup using rsync algorithm

Port: dvdbackup-0.1.1_2. Info: Backup content from DVD to hard disk

Port: flexbackup-1.2.1. Info: Perl-based flexible backup system that can use dump/afio/cpio/tar/star

Port: fsbackup-1.2.1. Info: File system backup and synchronization utility

Port: hdup-2.0.14. Info: The little, spiffy, backup tool

Port: kdar-2.0.7. Info: KDar is KDE-based backuptool using libdar

Port: nwclient-5.5.2_1. Info: Network backup client to NetWorker servers

Port: nwclient-6.0.2_2. Info: Network backup client to NetWorker servers

Port: pdumpfs-1.3. Info: A daily backup system similar to Plan9's dumpfs

Port: pdumpfs-clean-1.5. Info: A utility to clean up old backup files of a pdumpfs archive

Port: rdiff-backup-1.0.4,1. Info: Local/remote mirroring+incremental backup

Port: rdiff-backup-devel-1.1.5. Info: Local/remote mirroring+incremental backup

Port: reoback-1.0. Info: Simple but flexible ftp/nfs backup script

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


Вариант №3

Потерпев неудачу с bacula, я решил поискать ответа в «опыте прошлых поколений», а заодно и проанализировать поставленную задачу.


Чем заменить bacula?

В самом деле, что от меня требуется? Необходимо, чтобы некое ПО брало папку и ужимало её в некий архив. При этом будет хорошо, если ПО это способно будет сообразить, какие файлы изменились и их следует добавить в архив, а какие изменений не претерпели и их можно проигнорировать. Всё это – функции обычного стандартного архиватора. К примеру, RAR, или ZIP. Если создавать архив с ключём u (что значит update – обновление), то в архив будут включаться только новые и изменённые файлы. При этом удаление файла не приводит к тому, что при последующем архивировании он будет удалён из архива. В созданном таким образом архиве будут содержаться исключительно самые свежие версии каждого файла. Причём каждый файл в нём будет содержаться в единственном числе, что изрядно экономит место на дисках. Таким образом, получилось, что в моём случае для резервного копирования вполне достаточно обычного архиватора. Какого же? Оказалось, что в системах семейства Unix со времён мезозоя используется архиватор tar. Вполне приличный архиватор командной строки. При этом устанавливать его (и где-то для этого искать, что существенно) не надо – он всегда есть. Он позволяет производить архивацию с ключём update, что мне совершенно подходит. Сохраняет структуру каталогов в архиве, что тоже более, чем кстати. В общем – tar оказался тем самым инструментом. Но как же им пользоваться?

Вообще-то, есть понятие man tar, в котором всё подробно написано. Необходимо попасть в каталог, который мы хотим заархивировать, и дальше действовать. Впрочем, даже в каталог попадать необязательно. Но необходимо понять, что в нашем случае tar может использоваться в двух режимах – создание архива и обновление архива. Вот команда для обновления архива:

tar -u -f /backupfolder/bacup.tar /sourcefolder/*

Ключ -u указывает, что архив следует обновлять. Ключ -f /backupfolder/backup.tar говорит архиватору, над каким архивом следует производить действия. Параметр /sourcefolder/* указывает, что архивированию следует подвергнуть всё, что найдётся в каталоге /sourcefolder.

Таким образом, предположим, что в каталоге /usr/home (вспомним, на нашем сервере этому каталогу отдано наибольшее количество дискового пространства) имеются две папки – share1 и share2 – отданные в общий доступ с помощью samba. И именно эти папки мы хотим резервировать. Кроме того, нам надо куда-то складывать резервные копии. Пусть пока это будет папка backup, также располагающаяся в папке /usr/home. В таком случае наше архивирование будет выглядеть следующим образом:

tar -u -f /usr/home/backup/share1.tar /usr/home/share1/*

tar -u -f /usr/home/backup/share2.tar /usr/home/share2/*

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

Выполнив обе команды, мы могли бы ожидать, что в папке /usr/home/backup появятся два архива (иногда их называют тарболами) с содержимым общих папок. Однако фокус не получится! Дело в том, что tar умеет обновлять (ключ -u) только уже реально существующие архивы. При этом, что тоже важно, обновлять он может исключительно несжатые архивы, и именно поэтому в приведённых мной командах вы не найдёте ключа, приказывающего архиватору сжать пакуемые файлы. Однако, где же нам взять существующий несжатый архив?

Решение простое – выполнить приведённые выше команды, только вместо ключа -u использовать ключ -c, который и велит архиватору создать новый архив на пустом месте и поместить в него все файлы из указанных папок. Ну а дальше этот архив можно обновлять, как написано выше.


Как положить архивы на сторонний сервер?

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

Во-первых, нужно это самое место создать. Для этого на сервере BackServer создадим общую папку под названием backup. Почему английскими? Потому что свою FreeBSD я не русифицировал и потому не уверен, что она сможет работать с русскими именами файлов и папок. Кроме того, мне всё равно, а пользователям до этой папки дела нет. И чтобы доказать, что им нет до неё дела, я при создании этой папки выставляю для неё разрешения на чтение и запись только для себя – остальным там делать нечего.

Итак, папка создана. Как бы теперь организовать обращение к ней из моей FreeBSD? Если бы это была Windows, я смог бы написать что-то типа \\BackServer\backup. Если бы это был мой линукс с KDE, я смог бы в Конквероре написать smb:\\BackServer\backup. К несчастию, моя FreeBSD – это ни то, ни другое. Что делать?

Не стоит отчаиваться. Дело в том, что в системах семейства Unix имеется возможность легко и просто подмонтировать к существующей файловой системе любое внешнее хранилище, сделав его, тем самым, частью вашей системы, как если бы оно располагалось на вашем жёстком диске. В нашем случае речь идёт о внешнем файловом хранилище, расположенном на сервере под управлением MS Windows. Взаимодействие между Unix и Windows на уровне файловых операций осуществляется по протоколу SMB и реализовано сервером и клиентом samba. Таким образом, для сервера FreeBSD созданный нами сетевой ресурс backup на сервере BackServer будет самба-ресурсом. И мы сможем примонтировать его в нужное место нашей файловой системы с помощью команды mount_smbfs:

mount_smbfs //admin@backserver/backup /usr/home/backup

В этой команде параметр /usr/home/backup – та папка, в которую монтируется содержимое сетевого ресурса. То есть, после успешного монтирования мы будем работать с папкой /usr/home/backup как с локальной папкой, но все наши действия будут перенаправляться системой в сеть на сетевой ресурс \\BackServer\backup. Параметр же //admin@backserver/backup строится по следующему принципу - //пользователь@сервер/ресурс. Здесь «пользователь» - имя пользователя, под чьими учётными данными планируется работать на сетевом ресурсе (в нашем случае – администратор домена); «сервер» - NetBIOS-имя сервера, на котором расположен интересующий нас ресурс (в нашем случае – BackServer); «ресурс» - имя сетевого ресурса, с которым мы хотим работать.

Успешно выполнив эту команду, мы можем перейти в папку /usr/home/backup и увидеть её содержимое, на самом деле расположенное на другом сервере. С учётом того, что эта папка только что создана на своём сервере, она будет пустой. Однако скопировав туда что-нибудь, мы можем обнаружить, как оно моментально появилось и на сервере BackServer. Но!

Введя такую команду, мы обнаружим, что система требует от нас ввести пароль для пользователя admin. Причём ввести руками, с клавиатуры. Если мы работает руками и самостоятельно набираем все эти команды, то здесь проблем не возникнет – ввёл пароль и дело в шляпе. Но мы-то планируем делать резервное копирование автоматически! И какой автомат, хотелось бы знать, будет вводить этот пароль тёмной ночью, на которую запланировано наше резервирование? И если его вводить некому (а так оно и есть), то куда деваться и как быть с автоматизацией?

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

ls -l > ls.txt

Эта команда выводит подробное содержимое каталога, но выводит его не на экран (стандартный вывод), а в текстовый файл ls.txt, который создаётся в текущем каталоге. Собственно, здесь символ '>' и является той самой трубой, по которой вывод команды ls поступает в текстовый файл. Другой вариант – некая команда, требующая ввода с клавиатуры – интерактивная команда:

интерактивная_команда < file.txt

В этом случае всё, что необходимо ввести с клавиатуры, можно поместить в простой текстовый файл file.txt и по трубе '<' передать выполняемой команде. Экономится время, да и ошибку допустить труднее, особенно если вводить надо постоянно одно и то же. Совсем наш случай – почему бы не передать пароль для команды mount_smbfs по трубе из какого-нибудь файла! К примеру, вот так:

mount_smbfs //admin@backserver/backup /usr/home/backup < password.txt

Создаём текстовый файл password.txt, в него пишем открытым текстом пароль пользователя admin, и выполняем написанную выше команду (только учтите, что надо указать полный путь к файлу password.txt).

Команде, однако, наши трубы совершенно фиолетовы! Она как просила ввести пароль с клавиатуры, так и продолжает просить, самым наглым образом наплевав на все наши трубопроводы. Таким образом, приходим к выводу, что по трубам передаётся всё, что угодно, но только не пароли. И что же делать?

Самый простой выход – ознакомиться, наконец-то, со страницами man mount_smbfs. Из этих мануалов мы видим, что все необходимые параметры для подключения к сетевому ресурсу команда mount_smbfs получает из трёх мест:

  1. Сначала из файла /etc/nsmb.conf

  2. Если в файле /etc/nsmb.conf про данный ресурс ничего толкового не сказано, то информация ищется в файле ~/.nsmbrc.

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

На самом деле сначала команда mount_smbfs читает файл ~/.nsmbrc, находящийся в домашней папке пользователя, запускающего эту команду (здесь символ тильды именно обозначает домашнюю папку пользователя). Потом, вне зависимости от того, что обнаружилось в файле ~/.nsmbrc, читается файл /etc/nsmb.conf. Если в этом файле тоже есть настройки для нашего сетевого ресурса, то они перекроют настройки из файла ~/.nsmbrc. Ну и, само собой, если в обоих файлах ничего не обнаружено, то запрашивается ввод с клавиатуры. При этом следует учесть, что файл /etc/nsmb.conf появляется в системе в момент установки пакета samba (без которого общение с сетевыми ресурсами для нас вообще невозможно), тогда как файлы ~/.nsmbrc для пользователей не создаются вовсе.

Таким образом, для автоматизации работы команды mount_smbfs нам достаточно будет соответствующим образом отредактировать файл /etc/nsmb.conf. Вот он для нашего примера:

# $FreeBSD: src/etc/nsmb.conf,v 1.4 2002/04/22 16:18:36 sheldonh Exp $

#

# smbfs lookups configuration files in next order:

# 1. ~/.nsmbrc

# 2. /etc/nsmb.conf - if this file found it will

# override values with same keys from user files.

#

#

# This file consist from a set of sections. Each section started by section name

# surrounded with square brackets:

# [section_name]

#

# End of the section marked either by new section or by the end of file.

# Each section can contain zero or more parameters:

# [section_name]

# key=value

#

# where 'key' represents parameter name and 'value' a value assigned

# to this parameter.

#

# SMB library uses next forms of section names (please note that the section

# name should be in upper case when it refers to server, user or share):

# A) [default]

# B) [SERVER]

# C) [SERVER:USER]

# D) [SERVER:USER:SHARE]

#

# Here is the map of possible keywords:

#

# keyword/section A B C D Comment

#

# addr - + - - IP or IPX address of SMB server

# charsets + + + + local:remote charset pair

# nbns + + - - address of NetBIOS name server (WINS)

# nbscope + + - - NetBIOS scope

# nbtimeout + + - - timeout for NetBIOS name servers

# password - - + + a plain text password used to access to the given share

# retry_count + + - - number of retries before connection marked as broken

# timeout + + - - SMB request timeout

# workgroup + + + + name of workgroup

#


# A simple configuration example:


# First, define a workgroup.

[default]

workgroup=MYDOMAIN


# The 'FSERVER' is an NT server.

[BACKSERVER]

#charsets=koi8-r:cp866

addr=backserver.mydomain.local


[BACKSERVER:ADMIN]

# use persistent password cache for user 'joe'

password=наикрутейший_пароль_из_всех_возможных

В секции default необходимо указать NetBIOS-имя нашего домена. Для домена MyDomain.local таковым будет являться MYDOMAIN. Дальше следует секция для сервера, с ресурсами которого нам необходимо работать – BackServer.MyDomain.local. Для этого сервера – секция BACKSERVER. Обратите внимание, что название секции здесь обязано писаться большими буквами. В качестве названия для секции выступает NetBIOS-имя соответствующего сервера. Соответственно, если мы планируем работать не с одним единственным сервером, то и количество секций (и их названия) должно соответствовать. В этой секции достаточно указать полное доменное имя нашего сервера (маленькими буквами, как записано в DNS-базе). Присутствующие в данной секции параметры для кодовых страниц мной сознательно опущены, т.к. я не русифицировал свою FreeBSD и планирую пользоваться исключительно латиницей, а ей эти параметры – без разницы. Ну и, наконец, секция BACKSERVER:ADMIN содержит пресловутый пароль, который позволит пользователю admin работать с ресурсами сервера BackServer. Название секции пишется тоже большими буквами, пароль же – открытым текстом. При этом необходимо понимать, что имя пользователя и пароль его будут проверяться контроллером домена, так что и то, и другое должно присутствовать в домене. Иными словами, здесь указывается имя пользователя и пароль для администратора домена (в нашем случае).

Отредактировав файл /etc/nsmb.conf, попытаемся запустить команду mount_smbfs ещё раз. Получилось? Ну и славно! Если нет – ищем, где и что сделано неправильно. Потому как если у меня работает, то оно работает в принципе. В конце концов, я тоже первый раз столкнулся с FreeBSD...

Прежде, чем продолжить, обсудим ещё два момента, связанных с монтированием сетевого ресурса под FreeBSD.

Во-первых, почему бы нам не смонтировать этот сетевой ресурс один раз руками (вводя пароль с клавиатуры) и не пользоваться им в дальнейшем? Ответ прост – наш сервер может самопроизвольно перезагрузиться. К примеру, на выходных временно отключали электричество. Используемый мной источник бесперебойного питания, разумеется, поддерживает работу всех серверов моей сети на протяжении пары часов, но... А что, если электричество вырубят на сутки? Сутки мой ИБП не протянет, а ИБП, способный продержать сутки три сервера, стоит огромных денег и экономически просто нецелесообразен. Таким образом, необходимо подумать о сохранности сервера. Что и происходит автоматически при использовании ИБП.

При отключении внешнего напряжения ИБП отдаёт соответствующую команду серверам, и те по истечении некоторого промежутка времени начинают выключаться. Соответственно, выполняются все положенные при отключении скрипты и процедуры и сервер спокойно прекращает свою работу. Предварительно в журнал событий, что тоже вполне естественно, вносится запись, что сервер выключался в связи с такими-то событиями. Последними гаснут системные блоки – теперь сервер полностью выключен и ему нет никакого дела до поведения электросети.

Предположим, через час после выключения серверов в сети снова появилось напряжение. Оказывается, сервер вполне способен уловить этот момент и включиться автоматически. Что он и делает. При этом какому-либо пользователю регистрироваться на сервере совершенно необязательно – сервер будет исполнять свои функции и без этого. Но!

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

При этом, как ни странно, автоматический процесс резервного копирования по нашей схеме всё равно будет происходить, но резервные копии будут помещаться не на сетевой ресурс, а в локальную папку /usr/home/backup. И мы об этом не узнаем, пока не попытаемся воспользоваться резервной копией по прямому назначению – что-то восстановить. Только будет уже поздно – бардак организован.

Даже более того! Мы же не создаём каждый раз архив, а обновляем существующий. Но он существует на сетевом ресурсе, а не в локальной папке /usr/home/backup. Если сетевой ресурс не примонтируется, то архиватор не сможет обновить архив (напомним, что при работе tar с ключём -u целевой архив уже должен существовать и быть несжатым). То есть, с момента такой скрытой перезагрузки резервные копии не будут создаваться. Подозреваю, объяснять, почему это недопустимо, нет нужды.

Однако всего этого можно избежать, если монтировать сетевой ресурс в момент загрузки сервера. Это делается путём добавления соответствующей команды в стартовый скрипт. Однако команда эта, как ни странно, тоже должна выполняться автоматически, без запросов чего бы то ни было с клавиатуры. Так что в этом случае указанные манипуляции с конфигурационными файлами самба-клиента столь же необходимы, как и в нашем случае. Впрочем, я бы не советовал этого делать. Потому, что смонтированный при загрузке ресурс остаётся смонтированным до следующей перезагрузки. А поскольку unix-сервера весьма и весьма стабильны при работе, то этот период может спокойно равняться нескольким месяцам. За это время может многое произойти. К примеру, с утра пораньше можно начать и к вечеру закончить процедуру смены физического сервера BackServer. Просто с утра старый сервер отключить, поставить вместо него новый, установить на него систему, настроить и запустить. А старый выкинуть в окно. Но что произойдёт в процессе всех этих подключений и переключений с примонтированным сетевым ресурсом? Трудно сказать. Я лично подобных экспериментов не производил, но имеются у меня подозрения, что после такой смены сервера с ресурсом нельзя будет работать и его придётся монтировать заново.

При использовании первоначального варианта такой проблемы нет. Достаточно, чтобы тёмной ночью, когда запланирован процесс резервного копирования, в сети имелся сервер BackServer и на нём была общая папка backup с архивами, которые мы планируем обновлять. В таком случае наш сервер FreeBSD монтирует этот сетевой ресурс, делает своё дело и ресурс демонтирует. Что происходит с ресурсом в течение дня – его не интересует.


Подготовка к резервному копированию.

Итак, мы уже знаем, как мы будем проводить резервное копирование. Создадим на сервере BackServer общую папку backup, смонтируем её в папку /usr/home/backup. В смонтированной папке создадим нужные нам архивы, которые потом и будем обновлять. Пусть, к примеру, требуется архивировать папки /usr/home/share1, /usr/home/share2 и /usr/home/share3. В этом случае нам необходимо последовательно выполнить такие команды:

mount_smbfs //admin@backserver/backup /usr/home/backup

tar -c -f /usr/home/backup/share1.tar /usr/home/share1

tar -c -f /usr/home/backup/share2.tar /usr/home/share2

tar -c -f /usr/home/backup/share3.tar /usr/home/share3

cd /usr/home

umount /usr/home/backup

При этом предполагается, что конфигурационные файлы самба-клиента приведены нами в должный вид, так что монтирование сетевого ресурса не требует ввода пароля с клавиатуры. Кроме того, все команды вводятся, разумеется, с правами root. Каждую папку мы архивируем в отдельный архив, дабы в случае пожара не потерять всё разом. Расширение TAR для архива – архитектурное излишество. Можно вообще никакого расширения не присваивать, но я бы всё-таки рекомендовал это сделать, причём поставить именно расширение tar. Позже объясню, для чего это может пригодиться. Предпоследняя команда позволяет нам гарантированно выйти из папки /usr/home/backup, чтобы мы могли уверенно демонтировать её последней командой. Дело в том, что если мы будем находиться в этой папке, система не позволит демонтировать её, объявив занятой.

По окончании всех этих манипуляций мы обнаружим, что в папке backup на сервере BackServer появились три архива, а папка /usr/home/backup пуста. Всё готово к запуску процесса резервного копирования.


Создание скрипта.

Как мы уже говорили, процесс резервного копирования должен быть автоматическим – это одно из главных условий. Таким образом, все те команды, которые мы должны были бы набирать с клавиатуры, необходимо превратить в одну команду – шелл-скрипт. Аналог шелл-скрипта в системах на базе MS-DOS – пакетный файл *.bat. А назначение его – всего лишь заменить последовательность команд командной оболочки (уж простите за тавтологию) на одну команду.

В нашем случае сначала необходимо примонтировать сетевой ресурс в папку /usr/home/backup – команда mount_smbfs. В папке этой тут же появятся три наших архива, которые нам и надо обновить командой tar с ключём -u. По окончании обновления необходимо вывалиться из папки /usr/home/backup, если мы туда каким-то образом умудрились забраться – команда cd. Ну и, наконец, демонтировать сетевой ресурс, чтобы вернуть всё в исходное состояние – команда umount. Выпишем же себе последовательность действий:

mount_smbfs //admin@backserver/backup /usr/home/backup

tar -u -f /usr/home/backup/share1.tar /usr/home/share1

tar -u -f /usr/home/backup/share2.tar /usr/home/share2

tar -u -f /usr/home/backup/share3.tar /usr/home/share3

cd /usr

umount /usr/home/backup

Именно такие команды и именно в такой последовательности должен выполнить наш сервер. Если бы это была система семейства MS Windows, я бы создал файл backup.bat, куда бы и вписал приведённые команды один к одному. Но у нас – семейство Unix, а там понятия пакетного файла не существует в принципе. Зато есть шелл-скрипты. Стало быть, нам надо превратить написанное выше в шелл-скрипт. Выглядит это вот так:

############################################################################

# Copyright (C) 2006 by Haudh #

# haudh@yandex.ru #

# #

# This program is free software; you can redistribute it and#or modify #

# it under the terms of the GNU General Public License as published by #

# the Free Software Foundation; either version 2 of the License, or #

# (at your option) any later version. #

# #

# This program is distributed in the hope that it will be useful, #

# but WITHOUT ANY WARRANTY; without even the implied warranty of #

# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the #

# GNU General Public License for more details. #

# #

# You should have received a copy of the GNU General Public License #

# along with this program; if not, write to the #

# Free Software Foundation, Inc., #

# 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA. #

############################################################################

# $Id: cron_backup,v 1.3 2006/01/27 22:40:00 faure Exp $

# asd - Copyright (C) 2006 Haudh <haudh@yandex.ru>

#!/bin/sh

#Shell-script for unattended backup

#of shared folders on FreeBSD.MyDomain.local


#Mounting network share

mount_smbfs //admin@backserver/backup /usr/home/backup


#Updating backups

tar -u -f /usr/home/backup/share1.tar /usr/home/share1/*

tar -u -f /usr/home/backup/share2.tar /usr/home/share2/*

tar -u -f /usr/home/backup/share3.tar /usr/home/share3/*


#Unmounting network share

cd /usr

umount /usr/home/backup

При этом всё, что начинается с символа #, является комментарием и никак на наш скрипт не влияет. Всё это – архитектурные излишества, призванные нам облегчить чтение и понимание скрипта. Собственно, такие комментарии генерирует Kdeveloper при попытке создать в нём обыкновенный шелл-скрипт. Меня лично они поразили и очень понравились, а потому приведу их тут целиком.

Но один комментарий должен присутствовать обязательно - #!/bin/sh. Это – не совсем комментарий. Из этой строки ясно, какой оболочкой (shell – оболочка, отсюда и шелл-скрипт) необходимо воспользоваться для выполнения этого скрипта. В принципе, в нашем распоряжении имеется набор четырёх оболочек – sh, bash, csh и tcsh. И в любой из них можно сочинить нужный скрипт. К примеру, для пользователя root у меня была выставлена оболочка csh, а посему и шелл-скрипт было бы логично писать для неё, но не всё так просто. Пока не объясняю (чуть позже сами увидите), но для нашего скрипта должна быть избрана именно оболочка sh. Отсюда и этот хитрый комментарий. Всё остальное – ничуть не изменённые команды, последовательность коих мы с вами и установили.

Таким образом, нам необходимо создать текстовый файл, содержимое коего и приведено выше. Разумеется, комментарии можно и выкинуть – это не принципиально. Назвать наш файл следует, к примеру, cron_backup, а сохранить следует, к примеру, в /usr/sbin. Почему cron_backup? Потому что за запуск команд по расписанию отвечает демон под названием cron, откуда и проистекает первая часть названия. Ну а вторая часть вполне определённо указывает, что этот скрипт делает. Почему сохранять в /usr/sbin? Ну, хотя бы потому, что в этой папке (а также в /bin, /sbin, /usr/bin, /usr/local/bin и /usr/local/sbin принято хранить исполняемые файлы. Почему без расширения? Просто потому, что расширение может и означать что-то для нашей ОС, а нам этого не надо. Кроме того, я заметил, что в системах семейства Unix вообще не принято исполняемым файлам давать расширения.

Теперь можно попытаться запустить наш скрипт, дабы проверить, работает ли он. Делается это до неприличия просто – командой /usr/sbin/cron_backup. Ввели команду? Ну и славно, полученная вами ошибка означает, что исполнение данного файла запрещено. Дело в том, что кроме прав на чтение и на запись в ОС семейства Unix отдельной строкой прописано право на исполнение. Если вы введёте команду ls -l /usr/sbin/cron_backup, то вы получите нечто наподобие следующего:

-rw-r--r-- 1 root wheel 1210 Feb 21 11:53 cron_backup

Первые 10 символов этой строки и есть права на этот файл. Причём самый первый символ является признаком папки. Если бы это был не файл, а каталог, то там стояла бы буква d. Следующие три символа - «rw-» - означают, что владелец файла имеет право читать этот файл – r, записывать в него – w, но не имеет права исполнять его – символ -. Если бы у него такое право было, то там стояла бы буква x. Владельцем файла, кстати, является root, что отмечено здесь же. Группой, к которой принадлежит владелец файла, является группа wheel, что тоже отмечено в этой строке. Следующие три символа прав доступа - «r--» - как раз и описывают права на этот файл для остальных членов группы wheel. Оставшиеся три символа - «r--» - описывают права всех остальных пользователей системы на этот файл. Обозначение прав – такое же, как и в первом случае. Таким образом, теперь понятно, почему мы не смогли запустить этот скрипт. И понятно, что нам надо сменить права на него – разрешить его запуск. Как? Очень просто – командой chmod:

chmod +x /usr/sbin/cron_backup

Если мы теперь выполним команду ls для этого файла, как сделали это выше, то получим:

-rwxr-xr-x 1 root wheel 1210 Feb 21 11:53 cron_backup

Вот теперь можно смело запускать этот скрипт:

/usr/sbin/cron_backup

В ответ машина задумается на некоторое время (зависит от скорости вашей сети, степени шустрости серверов и объёмов папок, которые мы архивируем) и снова выдаст командную строку. Никаких сообщений не будет. Ну и как проверить, сработал ли скрипт, или только притворился, что что-то делает?

Во-первых, можно заглянуть в папку /usr/home/backup. Если она пуста, то это означает, что она была отмонтирована. Хотя, впрочем, пока ещё нет доказательств, что её вообще монтировали. Но если засечь время, в которое мы запустили свой скрипт, то можно посмотреть на дату изменения архивов в папке \\BackServer\backup и убедиться, что они изменились как раз в момент запуска нашего скрипта. Впрочем, колебания в пару минут в обе стороны всё равно возможны, если внутренние часы серверов не синхронизированы. Но самый оптимальный вариант таков – поместить в папку, подверженную архивированию, какой-нибудь файл (и запомнить имя файла, само собой), запустить ещё раз наш скрипт, а потом заглянуть в архив соответствующей папки на предмет выяснить, появился ли там наш проверочный файл. Если появился, то всё в порядке и скрипт работает. Если нет – где-то была допущена ошибка. При этом следует учесть, что архивы *.tar легко и просто открываются современными архиваторами (к примеру, WinRAR это точно умеет), так что исследовать их содержимое не составит труда. При этом архиваторы, написанные под MS Windows ориентируются именно на расширение файла, так что мы, присвоив нашим архивам расширение tar, очень себе помогли.


Демонификация.

Итак, мы подготовили скрипт и всё необходимо для его работы. Стоит наш скрипт запустить, как он тут же произведёт резервное копирование наших папок. Но пока мы его запускали руками. А надо – автоматически. Причём желательно, чтобы автоматический запуск происходил не абы когда, а ночью. Ну, скажем, в 3:15 каждую ночь. Почему ночью? Потому что в процессе архивирования по сети передаются значительные объёмы данных – ведь наши архивы лежат на сетевом ресурсе, а не на самом сервере. Соответственно, если бы такое происходило среди рабочего дня, то работа пользователей значительно бы осложнилась. В конце концов, пропускная способность сети не бесконечна, а днём ей выше крыши хватает тех пакетов, которые гоняют по ней пользователи – Интернет (и почта, и аська, само собой) да работа с файлами и папками, лежащими в сети (а то и сетевая база данных, а вдруг ещё и потоковое мультимедиа в сети – всякое возможно). Таким образом, процесс резервного копирования среди рабочего дня будет происходить значительно медленнее, нежели ночью, при свободной и ничем не занятой сети. Кроме того, этот процесс изрядно осложнит жизнь пользователям, за что админу едва ли кто скажет доброе слово. Кроме того, кто знает, какие светлые мысли по поводу издевательств над серверами придут в нашу светлую голову. А вдруг я решу их просто перезагрузить? А в это время полным ходом идёт архивирование. Так ведь и данных всех лишиться можно. Короче, тёмная ночь – самое оптимальное время. И сразу вопрос – кто же придёт и запустит наш скрипт на нашем сервере среди ночи? Ответ прост – это будет демон.

Но не тот демон, который страшно смеётся и преследует всяческих положительных героев, надумавших бороться с Силами Зла. Наш демон зовётся cron (от chronos – время) и обеспечивает автоматическое выполнение различных команд в системе семейства Unix по заранее составленному расписанию.

Собственно, понятие «демон» в системах семейства Unix соответствует понятию «сервис» в системах семейства MS Windows. Это некая программа, запускаемая при старте компьютера и в фоновом режиме обрабатывающая различные наступающие в системе события. Откройте Диспетчер Процессов своей MS Windows и вы увидите довольно внушительный список сервисов, выполняющихся в ней, пока вы спокойно читаете эту страницу. Если же у вас не Windows, а клон Unix, то наберите в командной строке ps -ax | more, и вы получите список выполняющихся в настоящий момент процессов, добрая половина коих является демонами. Вот кусок этого списка с моей машины:

2143 ? S 0:00 clamd -c /etc/clamd.conf

2178 ? S 0:00 /usr/bin/freshclam --config-file=/etc/freshclam.conf --quiet --daemon

2227 ? S 0:00 crond

2263 ? S 0:00 smbd -D

2273 ? S 0:00 nmbd -D

Средняя позиция в приведённом куске списка – как раз демон cron, запускаемый при загрузке компьютера.

Как мы уже сказали, демон cron осуществляет запуск команд по заранее заданному расписанию. Соответственно, он должен где-то хранить это расписание. Где же?

Расписание, с которым сверяется демон cron, называется таблицей crontab. Существуют два типа таких таблиц. Тип первый – головная таблица crontab. Эта таблица содержит расписание, общее для всей системы. Иными словами, сюда внесены команды, исполнение которых не должно зависеть от желания (или нежелания) пользователей нашей системы. К примеру, обновление системы или антивирусная её проверка. Эти команды относятся не к пользователям, а к собственно системе. Хранится головная таблица в файле /etc/crontab.

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

crontab -u user file

Здесь user – имя пользователя, которому будет принадлежать таблица, а файл – созданный нами текстовый файл, содержимое коего требуется преобразовать в таблицу этого пользователя. Пусть, к примеру, пользователь vasia создал себе текстовый файл /usr/home/vasia/vasiatab.txt со своей таблицей пользователя. Чтобы сделать её активной, ему необходимо ввести команду:

crontab -u vasia /usr/home/vasia/vasiatab.txt

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

Поскольку в нашем случае задание резервного копирования вполне можно считать всеобщим и от конкретного пользователя не зависящим, имеет смысл вносить его в головную таблицу. Для этого достаточно отредактировать файл /etc/crontab соответствующим образом. Вот пример обычного файла головной таблицы:

# /etc/crontab - root's crontab for FreeBSD

#

# $FreeBSD: src/etc/crontab,v 1.32 2002/11/22 16:13:39 tom Exp $

#

SHELL=/bin/sh

PATH=/etc:/bin:/sbin:/usr/bin:/usr/sbin

HOME=/var/log

#

#minute hour mday month wday who command

#

*/5 * * * * root /usr/libexec/atrun

#

# Save some entropy so that /dev/random can re-seed on boot.

*/11 * * * * operator /usr/libexec/save-entropy

#

# Rotate log files every hour, if necessary.

0 * * * * root newsyslog

#

# Perform daily/weekly/monthly maintenance.

1 3 * * * root periodic daily

15 4 * * 6 root periodic weekly

30 5 1 * * root periodic monthly

#

# Adjust the time zone if the CMOS clock keeps local time, as opposed to

# UTC time. See adjkerntz(8) for details.

1,31 0-5 * * * root adjkerntz -a

Сразу обратим внимание на строку SHELL=/bin/sh. Эта строка указывает демону cron, в какой командной оболочке исполнять перечисленные в расписании команды. Почему в качестве оболочки выбрана именно sh и можно ли использовать другую, указав её в этой строке, я не знаю. Но это и не важно – для нашего скрипта это не принципиально. Более того, если вспомнить, то при написании скрипта мы использовали именно оболочку sh (строкой #!/bin/sh). Сделано это было как раз потому, что именно эта оболочка нужна демону cron.

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

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

А вот далее всё, что не является комментариями (комментарии, как и везде, начинаются с диеза - #) - расписания для запуска разных команд. На одну команду с одним расписанием приходится одна строка. Формат простой:

  1. Минуты

  2. Часы

  3. Дни месяца

  4. Месяцы

  5. Дни недели

  6. Пользователь

  7. Команда

Разделителями здесь могут быть пробелы или знаки табуляции (последние делают таблицу более читабельной, демону же – глубоко фиолетово). К примеру, в нашем случае задание резервного копирования должно запускаться каждый день (точнее, каждую ночь) в 3:15. Как это будет выглядеть? 3:15 – это три часа пятнадцать минут. Стало быть, минуты=15, часы=3. Дни месяца – все, какие есть, что обозначается символом «*». Месяцы – то же самое. Дни недели также не важны. Поскольку наш скрипт должен запускаться с правами root, то и пользователь=root. Командой же в данном случае служит сам скрипт. В итоге получим расписание для нашего резервного копирования в следующем виде:

15 3 * * * root /usr/sbin/cron_backup

Достаточно добавить эту строку в головную таблицу, и демон крон этой же ночью, ровно в 3:15 выполнит наш скрипт.


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


Обратим внимание на головную таблицу crontab, приведённую во врезке выше. Там, кроме всего прочего, имеются такие строки:

# Perform daily/weekly/monthly maintenance.

1 3 * * * root periodic daily

15 4 * * 6 root periodic weekly

30 5 1 * * root periodic monthly

Что это за строки? Буквальный перевод с английского того, что написано в комментарии, выглядит, как «провести ежедневное/еженедельное/ежемесячное обслуживание». Под таковым обслуживанием подразумевается выполнение некоего набора команд соответственно ежедневно, еженедельно и каждый месяц (точное расписание прекрасно видно из самой таблицы). Что это за команды?

Оказалось, что это не команды, а целый набор скриптов. Иными словами, имеется определённый набор скриптов, который запускается командами periodic daily, periodic weekly и periodic monthly в соответствии с расписанием, заданным в головной таблице crontab. Скрипты эти хранятся в папках /etc/periodic/daily, /etc/periodic/weekly и /etc/periodic/monthly соответственно. Вот, к примеру, листинг папки /etc/periodic/weekly с моего сервера:

total 14

-rwxr-xr-x 1 root wheel 1073 Nov 3 08:12 120.clean-kvmdb

-rwxr-xr-x 1 root wheel 619 Nov 3 08:12 310.locate

-rwxr-xr-x 1 root wheel 1007 Nov 3 08:12 320.whatis

-rwxr-xr-x 1 root wheel 1165 Nov 3 08:12 330.catman

-rwxr-xr-x 1 root wheel 621 Nov 3 08:12 340.noid

-rwxr-xr-x 1 root wheel 961 Nov 3 08:12 400.status-pkg

-rwxr-xr-x 1 root wheel 604 Nov 3 08:12 999.local

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

Таким образом, мы можем вставить свой скрипт резервного копирования в папку /etc/periodic/daily, чтобы обеспечить его исполнение в ходе ежедневного обслуживания системы. Что я и сделал:

-rwxr-xr-x 1 root wheel 679 Nov 3 08:12 300.calendar

-rwxr-xr-x 1 root wheel 1211 Nov 3 08:12 310.accounting

-rwxrwxrwx 1 root wheel 2083 Mar 2 11:06 320.cron-backup

-rwxr-xr-x 1 root wheel 710 Nov 3 08:12 330.news

-rwxr-xr-x 1 root wheel 516 Nov 3 08:12 400.status-disks

При этом мне пришлось присвоить скрипту номер, дабы он нашёл своё место в очереди исполнения набора скриптов. Мне показалось, что его место находится между скриптом accounting (отвечает за учётные записи пользователей, наверное) и скриптом news (какими новостями он занимается, мне неведомо). У первого номер – 310, у второго – 330. Соответственно, мне надо было присвоить своему скрипту номер между 310 и 330 – вполне логичным выглядел номер 320, хотя подошёл бы и 315, и 327 и любой другой из этого промежутка. Я, в соответствии со своим решением, изменил имя скрипта с /etc/periodic/daily/cron_backup на /etc/periodic/daily/320.cron_backup и, таким образом, запланировал себе ежедневное резервное копирование. Разумеется, права на исполнение скрипта должны быть выставлены.

На следующее утро я обнаружил в папке \\BackServer\backup свежие обновлённые архивы, что подтвердило работоспособность моего скрипта и, заодно, успешный запуск резервного копирования сервера FreeBSD. Задача решена.


Заключение

Итак, нам удалось осуществить резервное копирование живущего в домене сервера под управлением FreeBSD 6.0 с хранением резервных копий на сетевом ресурсе. При этом использовался минимум ПО (только встроенное ПО системы) и методика резервного копирования, применявшаяся на ранних стадиях развития компьютерных систем. Тем не менее, получены ежедневно обновляемые резервные копии всех документов сервера, к которым можно в любой момент обратиться.


Видимо, стоит несколько слов сказать и о восстановлении из таких резервных копий.

Восстановление в Windows

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

Восстановление во FreeBSD

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

Хостинг от uCoz