Системные администраторы бывают двух типов — те кто делает резервные копии, и те кто их будет делать.

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

Бороться с аппаратным сбоем помогает RAID, но как быть с шифровальщиками, которые на сегодняшний день принесли уже очень много горя.

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

Конечно linux тоже не панацея, его то же могут взломать, но ломают его гораздо реже. Чаще всего под ударам оказывается именно Windows, так как все таки большинство пользователей и соответственно хакеров пользуются именно им. Так что скажем так: linux безопаснее Windows по тому, что им реже пользуются.

По этому этим можно воспользоваться. Будем считать, что он защищен от взлома и проникновения вирусов.

В простейшем варианте я на сервер устанавливаю 3 жестких диска:

1. под хостовую систему и виртуальные сервера, на нем же находится (если виртуальный сервер — сервер 1с) сетевая папка для хранения архивов, скажем выгрузок 1С;
2. диск, который полностью попадет в ведение виртуальной машины, там будут крутиться рабочие данные;
3. диск для резервного копирования и системы виртуальных машин (на всякий случай для отката систем) и для резервного копирования всех данных с рабочего диска виртуальной машины, при чем данные с рабочего диска будут копироваться в две разные папки — одна для четных недель, другая для нечетных недель. Это сделано как раз таки для защиты от шифровальщиков, что бы случайно при копировании не получить зашифрованные данные и на рабочем диске и на диске с копиями. Разумеется этот диск должен быть раза в три больше рабочего диска.

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

Исходя из этих соображение, я настраиваю копирование один раз в неделю, причем по четным неделям данные попадают на диск с копиями например в папку Copy1, а по нечетным неделям — в папку Copy2.

Для данной процедуры создается скрипт (Copy.sh):

!/bin/bash
# Останавливаем виртуальную машину (даем команду на выключение)
#Если сервер заснул, то это его только разбудит (почему-то иногда именно так?)
sudo -H -u user /usr/bin/VBoxManage controlvm «vm_name» acpipowerbutton
#Даем время выключиться машине
sleep 10
#А вот теперь окончательно даем команду на выключение (если первая команда не сработала)
sudo -H -u user /usr/bin/VBoxManage controlvm «vm_name» acpipowerbutton
#Даем время выключиться машине
sleep 180
#Подключаем диски этой машины к заранее созданным папкам (здесь все NTFS)
# Лучше перейти на использование UUID, что бы не было проблем при прыгающих дисках
# для этого даем команду sudo blkid и теперь цепляем вот так
sudo mount /dev/disk/by-uuid/0640625C4062530B /media/user/Distrib1 -t auto -o rw,nls=utf8,noatime
sudo mount /dev/disk/by-uuid/9E847EF3847ECCF1 /media/user/SQL_Data1 -t auto -o rw,nls=utf8,noatime
sudo mount /dev/disk/by-uuid/DAD68E86D68E631D /media/user/SQL_Log1 -t auto -o rw,nls=utf8,noatime
sudo mount /dev/disk/by-uuid/02FAA6C6FAA6B577 /media/user/1C71 -t auto -o rw,nls=utf8,noatime
sudo mount /dev/disk/by-uuid/6CCE2488CE244CA0 /media/user/1C81 -t auto -o rw,nls=utf8,noatime
sudo mount /dev/disk/by-uuid/82DC36B7DC36A577 /media/user/ClientsBases1 -t auto -o rw,nls=utf8,noatime
sudo mount /dev/disk/by-uuid/98E24B5CE24B3E2E /media/user/Change1 -t auto -o rw,nls=utf8,noatime
sudo mount /dev/disk/by-uuid/C0725ABA725AB4BE /media/user/ARC1 -t auto -o rw,nls=utf8,noatime

# получение циферки текущей недели
week=»date +%W«
# остаток от деления на 2 числа недели
rests=»expr $week % 2«
# условие сравнения выходного статуса от деления
if [ $rests == «0» ]
then
# если неделя четная
echo «суда команды для копирования в четную папку»
else
# если неделя нечетная
echo «суда команды для копирования в нечетную папку»
fi
# А здесь общий принцип синхронизации (его вставить выше)
sudo -H -u user rsync -av —delete —ignore-errors /media/user/ARC1/ «/mnt/Copy/Disks/(M) ARC/»
sudo -H -u user rsync -av —delete —ignore-errors /media/user/Change1/ «/mnt/Copy/Disks/(L) Change/»
sudo -H -u user rsync -av —delete —ignore-errors /media/user/ClientsBases1/ «/mnt/Copy/Disks/(K) ClientsBases/»
sudo -H -u user rsync -av —delete —ignore-errors /media/user/1C81/ «/mnt/Copy/Disks/(J) 1C8/»
sudo -H -u user rsync -av —delete —ignore-errors /media/user/1C71/ «/mnt/Copy/Disks/(I) 1C7/»
sudo -H -u user rsync -av —delete —ignore-errors /media/user/SQL_Log1/ «/media/ceasar/SQL_Log1/»
sudo -H -u user rsync -av —delete —ignore-errors /media/user/SQL_Data1/ «/mnt/Copy/Disks/(G) SQL_Data/»
sudo -H -u user rsync -av —delete —ignore-errors /media/user/Distrib1/ «/mnt/Copy/Disks/(F) Distrib/»
# Отключаем ранее подключенные диски
sudo umount -f /media/user/Distrib1
sudo umount -f /media/user/SQL_Data1
sudo umount -f /media/user/SQL_Log1
sudo umount -f /media/user/1C71
sudo umount -f /media/user/1C81
sudo umount -f /media/user/ClientsBases1
sudo umount -f /media/user/Change1
sudo umount -f /media/user/ARC1
# Запускаем выключенную ранее машину
sudo systemctl stop vm_autostart@vm_name
sudo systemctl start vm_autostart@vm_name
# Даем время загрузиться машине
sleep 180
# Отключаем следующую машину
sudo -H -u user /usr/bin/VBoxManage controlvm «vm_name2» acpipowerbutton
# Даем время на отключение
sleep 180
# Подключаем диски к папкам которые заранее создали (Здесь EXT4)
# Лучше перейти на использование UUID, что бы не было проблем при прыгающих дисках
# для этого даем команду sudo blkid и теперь цепляем вот так
sudo mount /dev/disk/by-uuid/2af2c96f-6b90-4da7-8459-7abd8603fbb4 /media/user/zimbra1 -t ext4
sudo mount /dev/disk/by-uuid/15ec58ae-ca50-4844-b5da-b90a8264a792 /media/user/www1 -t ext4

# получение циферки текущей недели
week=»date +%W«
# остаток от деления на 2 числа недели
rests=»expr $week % 2«
# условие сравнения выходного статуса от деления
if [ $rests == «0» ]
then
# если неделя четная
echo «суда команды для копирования в четную папку»
else
# если неделя нечетная
echo «суда команды для копирования в нечетную папку»
fi
# А здесь общий принцип синхронизации (его вставить выше)
sudo -H -u user rsync -av —delete —ignore-errors —sparse /media/user/www1/ «/mnt/Copy/mail/www/»
sudo -H -u user rsync -av —delete —ignore-errors —sparse /media/user/zimbra1/ «/mnt/Copy/mail/zimbra/»
# Отключаем диски
sudo umount -f /media/user/www1
sudo umount -f /media/user/zimbra1
# Запускаем синхронизированную машину
sudo systemctl stop vm_autostart@vm_name2
sudo systemctl start vm_autostart@vm_name2

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