Что копируем?
Вернее, где было бы полезно описываемое решение? Представим себе офис небольшой компании. Компания, как правило, нуждается в бухгалтерской системе. Скажем 1С. 7-ка, 8-ка, не важно. Плюс надо где-то хранить надежно персональную информацию, которую бы не хотелось бы потерять, если вдруг что-то случится с локальным жестким диском. А случится может. Причем даже с довольно надежными и, казалось бы, проверенными моделями дисков.
Решением может быть покупка сервера под 1С и под шары пользователей. Ага. сервер. Но мы помним, что компания то небольшая и не всегда в бюджет заложены деньги на сам сервер (от 80 т.р.) и лицензионное серверное ПО от Miscrosoft (от 40 т.р.), которому несмотря на всю лицензионность без честного купленного антивируса все равно никуда. Почему я тут упомянул именно Майкрософт? И именно его серверные версии?
Мой личный опыт и опыт уважаемых мной коллег показывает, что обычно ситуация с 1С развивается таким образом. Мастера из 1С настраивают работу бухгалтерии на работу базы локально на одном компе, а другим пользователям после настраивают путь к файлам на папку на том компьютере, открывая к ней общий доступ. Но, при увеличение числа пользователей (компьютеров, присоединяемых к базам 1С, расположенным на сетевой шаре) 1С больше 3 начинают замечаться тормоза в работе 1С по сети.
Для решения этих проблем 1С-ники обычно и рекомендуют переходить на терминальную версию, а это и выливается в покупку боле менее надежного сервера и лицензионного серверного Виндоуса, ибо обычный поддерживает только один удаленный рабочий стол и все.
Мне же кажется боле менее разумным решение такого плана. В качестве сервера использовать обычную рабочую станцию (i3 и 4 Гб Озы хватит за глаза) + пара дисков на ней, настроенных как зеркалируемый RAID. А в качестве серверной ОС использовать проверенную лошадку - FreeBSD и SAMBA на ней.
Кстати, чтобы сетевых тормозов было поменьше при большом числе пользолвателей (не 100, конечно, на больше, чем 3. Скажем 10-15) помогают некоторые настройки ядра системы, метко названные "sysctl-гайками", рекомендованные на форуме FreeBSD. Я использую эти:
# Настройки для SAMBA
kern.ipc.maxsockbuf=2097152
net.inet.tcp.recvspace=262144
net.inet.tcp.sendspace=262144
net.inet.tcp.mssdflt=1452
net.inet.udp.recvspace=65535
net.inet.udp.maxdgram=65535
net.local.stream.recvspace=65535
net.local.stream.sendspace=65535
Настройку SAMBA и вообще всего этого описывать здесь не стану, ибо интернет кишит документацией по обеим этим вещам, а я тут просто рассказываю про решение вопроса резервного копирования работающей системы. Хотелось бы только отметить, что для наденой работы зеркалирования и оперативного получения резервных копий надо использовать FreeBSD на файловой системе ZFS, позволяющей делать очень много полезных вещей. Нам же пригодятся две их них:
- организация зеркалируемого хранилища;
- получение моментальных резервных копий файловых систем.
Помимо основных ФС, создаваемых скриптом установки zfsinstall (/, /var и / home), надо сделать еще одну, куда и будем сваливать дампы:
zfs create tank/noDumpFS
Полезным будет озаботится сохранением ежедневных копий файлов 1С. На случай, если кто-то по криворукости или с бодуна удалит в 1С несколько проводок. Имея сохраненные, делающиеся ночью архивы базы, можно запросто все вернуть на состояние сегодняшнего утра.
Очень полезно и даже просто необходимо регулярно мониторить состояние зеркала, а может даже и состояние жетских дисков пула, используя smartmontools. Я обычно ограничиваюсь ежедневной отсылкой на почту инфоромации о здоровье ZFS-пула:
#!/usr/local/bin/bash
HOSTNAME=`/bin/hostname`;
/sbin/zpool status -v | mail -s "ZPOOL Status on ${HOSTNAME}" root;
Если на почте в какой-нибудь прекрасный день вместо ONLINE мы увидели DEGRADED, то идем к начальству на предмет получения 3 т.р. на новый жесткий диск. Сама же система, скорее всего будет работоспособна, просто один из дисков будет из пула исключен. Купив диск, вставим его на место умершего, подключим его к зеркалу и продолжим счастливый полет.
Используя же smartmontools, и читая информацию из SMART-контроллера диска, мы можем предвосхитить появление надписи DEGRADED, заменив диск до его кончины.
Вот, казалось бы и все готово. Данные на двух дисках, вряд ли погибнут оба одновременно. Но, хоть и с минимальной вероятностью, но такое может случиться. Не знаю, как вам, а мне самому как-то не по себе, когда что-то важное лежит всего на одном компьютере.
А значит будем копировать полностью все основные файловый системы сервера. Куда? Да на любую клиентскую Виндоус-машину в сети. Сделаем на ней папку, дадим разрешения записывать в нее. По хорошему, доступ к этой папке лучше сделать по паролю. Я остановился на простом варианте, без пароля. Если Вам захочется, чтобы доступ был только после авторизации, то в вызове smbclient надо будет убрать параметр -N и поставить ключ --user=ИМЯ_ПОЛЬЗОВАТЕЛЯ%ПАРОЛЬ_ПОЛЬЗОВАТЕЛЯ.
Итак, вот два скрипта. Первый - проверяет, что в данный момент никто не использует сервис самба (не сидит в базе). Если так и есть, то скрипт останавливает сервис samba, делает моментальные снимки файловых систем, запускает samba заново и записывает снимки в файлы, сжимая их по пути.
#!/usr/local/bin/bash
# Проверяем, что нет соединений к SAMBA-шарам
CONNECT=`/usr/local/bin/smbstatus -S | /usr/bin/grep "Connected at" -A 2 | tail -n 1`;
if [ "$CONNECT" ];then
echo "Имеются подсоединенные клиенты";
echo "Первый этот - ${CONNECT}";
exit 1;
fi
echo "Подсоединенных клиентов нет. Можно останавливать Самбу";
/usr/local/etc/rc.d/samba stop;
# Делаем снимки файловых систем
/sbin/zfs snapshot tank/root@lastBackup;
/sbin/zfs snapshot tank/root/var@lastBackup;
/sbin/zfs snapshot tank/root/hosting@lastBackup;
/usr/local/etc/rc.d/samba start;
/sbin/zfs send tank/root@lastBackup | /usr/bin/gzip > /noDumpFS/FSDumps/rootFS.gz;
/sbin/zfs send tank/root/var@lastBackup | /usr/bin/gzip > /noDumpFS/FSDumps/varFS.gz;
/sbin/zfs send tank/root/home@lastBackup | /usr/bin/gzip > /noDumpFS/FSDumps/homeFS.gz;
# Удаляем снимки файловых систем
/sbin/zfs destroy tank/root@lastBackup;
/sbin/zfs destroy tank/root/var@lastBackup;
/sbin/zfs destroy tank/root/hosting@lastBackup;
Запуск этого скрипта можно настроить через cron по ночам.
Второй скрипт закидывает сделанные ночью дампы на Виндоус-машину (в моем случае под именем WINDOWS001 в шару server_backups, где есть папка FSDumps), его запуск надо настроить на то время, когда Виндоус-машина обычно включена.
#!/usr/local/bin/bash
WIN_MACHINE='WINDOWS001';
DUMPS_LOCAL_PATH="/noDumpFS/FSDumps";
/usr/local/bin/smbclient -N //${WIN_MACHINE}/server_backups -D FSDumps -c "ls;quit";
RES=$?;
if [ $RES -ne 0 ]; then
echo "Machine ${WIN_MACHINE} unreachable";
exit 1;
fi
echo "Machine ${WIN_MACHINE} ready to get dumps";
/usr/local/bin/smbclient -N //${WIN_MACHINE}/server_backups -D FSDumps -c "ls;put ${DUMPS_LOCAL_PATH}/rootFS.gz rootFS.gz;quit;";
/usr/local/bin/smbclient -N //${WIN_MACHINE}/server_backups -D FSDumps -c "ls;put ${DUMPS_LOCAL_PATH}/varFS.gz varFS.gz;quit;";
/usr/local/bin/smbclient -N //${WIN_MACHINE}/server_backups -D FSDumps -c "ls;put ${DUMPS_LOCAL_PATH}/homeFS.gz homeFS.gz;quit;";
exit 0;
Вот теперь, мне кажется, можно быть спокойным за сохранность данным 1С-бухгалтерии.
Комментарии к статье (1)
| 
