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

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

Но начну с такой информации…

Статья 274 УК РФ. Нарушение правил эксплуатации средств хранения, обработки или передачи компьютерной информации и информационно-телекоммуникационных сетей.

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

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

Разговор в камере:

— Тебя за что?

— Убил

— А тебя?

— А у меня хранилище упало… и бэкапов не было…

Итак… что необходимо бэкапить? Исходя из статьи 274 УК РФ — на всякий случай, всё и на несколько хранилищ…

Я выделил следующие направления:

• Бэкап виртуальных машин (на примере Hyper‑V)

• Бэкап баз данных MS SQL

• Бэкап баз данных Postgres

• Бэкап файлов

Бэкапы бывают полные и дифференциальные. Я приверженец полных бэкапов, и в этой статье рассмотрю только их. Да, дифференциальные бэкапы занимают намного меньше места и создаются намного быстрее, но при работе с ними могут возникнуть ошибки.

Бэкап виртуальной машины можно производить, использовав различное ПО, такое как Veem, DPM — но я использовал только Powershell — это дешевле и интересней.

Давайте сначала подумаем об архитектуре — выделю основные моменты:

• Хосты Hyper‑V находятся в изолированной сети;

• Имеется отдельный файловый сервер в этой же изолированной сети с расшаренной папкой для хранения бэкапов виртуальных машин;

• использование высокоскоростных интерфейсов (10 Гбит\с ) или агрегации портов для хранилища;

• Размер виртуальной машины ограничивать 200–300 ГБ;

• Создавать полную копию виртуальной машины;

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

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

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

Бэкапить виртуальные машины на два хранилища довольно затратная идея, поэтому рассмотрю пример с одним хранилищем. Хорошим решением является использование в качестве хранилища виртуальных машин такой системы как Ceph, когда образ виртуальной машины храниться на нескольких серверах, и регулируется самим Ceph‑ом. Но данная технология требует изучения, проектирования и тщательного внедрения, поэтому на начальных этапах все же лучше использовать более простые решения.

Итак, у нас есть примерно такая архитектура закрытой сети хостов Hyper‑V:

В сети есть и отдельные сервера Hyper‑V и кластеры Hyper‑V. Все сервера введены в домен.

На файловом сервере Storage Backup имеется общая папка, в которую будут складываться бэкапы. В настройках доступа и в настройках безопасности папки добавлены доменные учетки серверов Hyper‑V и узлов кластеров.

Основная команда в скрипте для бэкапа виртуальной машины:

Export-VM -Name $vm -Path $fullpath -ErrorAction Stop

где $vm – имя виртуальной машины;

$fullpath – путь (расшаренная папка), куда будет бэкапиться ВМ

Есть небольшая разница при бэкапе ВМ в кластере и на отдельно стоящих серверах Hyper‑V — в кластере неизвестно на каком узле кластера в данный момент располагается конкретная ВМ, поэтому сначала надо найти на каком хосте работает ВМ в данный момент, затем подключиться к этому хосту и начать бэкапить ВМ.

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

Назначенное задание в шедулере создается обычное, потому что кластерное задание выполняется из‑под учетки System, которой недоступны некоторые командлеты из скрипта — если здесь я не прав, поправьте меня, пожалуйста.

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

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

Для того чтобы подключение к кластеру произошло необходимо настроить делегирование учетных записей для wsman.

Здесь я столкнулся ошибкой: В настоящее время в конфигурации клиента отключена проверка подлинности CredSSP.

Нашел алгоритм действий, который для меня работает:

1) Необходимо настроить групповую политику: Конфигурация компьютера — Административные шаблоны — Система — Передача учетных записей — Разрешить передачу новых учетных данных.

2) Enable-WSManCredSSP -Role Client -DelegateComputer * -Force

3) Импорт рег-файла, который создаст ветку реестра: HKLM:\software\policies\microsoft\windows\CredentialsDelegation\AllowFreshCredentials и создаст в ней необходимые параметры.

Проверяем командой:

Get-WSManCredSSP

Вывод команды должен быть такой:

Параметры компьютера позволяют делегировать новые учетные данные следующим конечным объектам: wsman/*.

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

Но этому выводу не верим, поэтому проверяем запустив скрипт:

PowerShell.exe -NoLogo -NoProfile -File \\myserver\shareFolder\f.ps1 -vm f -path \\VMbackup\VM_Backup -LogPath \\VMbackup\VM_Backup -proverkaPaths 1 -K 4 -MinFreeSpace 3080 -vmoff 1 -us UsVer -pass "Morkovka10" -cluster 1

Скрипты и reg‑файл лежат здесь.

Управление назначенными заданиями в шедулере средствами powershell выполняется следующими командами:

•	Get-ScheduledTask
•	Start-ScheduledTask –TaskName Bugaga
•	Unregister-ScheduledTask Bugaga

Алгоритм действий такой:

1. Запускаем скрипт form.ps1

2. Заполняем имя ВМ, путь для бэкапов, путь для логов, количество бэкапов, дни недели, время, состояние ВМ при экспорте и жмем кнопку «Создать задание».
   

   

3. Смотрим в шедулер, должно появится задание, запускаем его для проверки.

Бэкапы баз данных

Теперь давайте разберемся с бэкапами БД на примере MS SQL SERVER и PostgreSQL

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

На MS SQL SERVER используем SQL Managenment Studio — Agent SQL Server — Задания.
При создании задания создаем 2 шага, один бэкапит на одно хранилище, второй на второе, но в этом случае необходимо настроить действия при удачном и неудачном выполнении шага.

А вот сам скрипт шага:

DECLARE @DISKSTR varchar (255)
SET @DISKSTR = '\\MyServer\ShareFoldre \nameDB\ nameDB _full_'
+ replace(convert(char(19),getdate(),120),':','-') + '.bak'
BACKUP DATABASE [nameDB] TO DISK = @DISKSTR WITH NOFORMAT, NOINIT, NAME = N' nameDB -Полная База данных Резервное копирование', SKIP, NOREWIND, NOUNLOAD, COMPRESSION, STATS = 10
GO

Расписание — чем чаще, тем лучше — но все зависит от хранилища.

БД бэкапится в общую папку, соответственно необходимо добавить в разрешения на папку на вкладках «Доступ» и «Безопасность» доменную учетку сервера, где запущен SQL SERVER.

На данном этапе имеем папку, куда бэкапиться множество разных БД, со временем хранилище забьется — поэтому необходимо сделать напоминалку на проверку свободного места в хранилище, либо настроить оповещения.

Получив уведомение о том что, место на хранилище закончилось, необходимо почистить папку либо вручную, либо использовать скрипт, например такой:

#папки, в которых нельзя удалять 
$NotDeletedFolders = @( '1c' , 'amti_buh')
#путь до расшаренной папке
$DirBackup= '\\gse264-11\backup_all\1c'
#перечень папок
$folders = Get-ChildItem $DirBackup
#количество бэкапов в месяц (все что больше этой цифры будет удаляться)
$ColFiles=5
Foreach($folder in $folders){
  if($folder.Name -NotIn $NotDeletedFolders){
    $files = Get-ChildItem $DirBackup\$folder
    $month=0
    $col=0
    Foreach($file in $files){
        $LastWriteTimeMonth = $file.LastWriteTime.Month
        if($month -eq $LastWriteTimeMonth){
        $col=$col+1
          if($col -gt $ColFiles){
             Remove-item $DirBackup\$folder\$file
             write "удалим файл - $DirBackup\$folder\$file" | out-file C:\log\delbak.txt -append 
          }
        }else{
            $month = $LastWriteTimeMonth
            $col=1
        }
     }
  }
} 

Что касается PostgreSQL, то он крутится у нас на Ubuntu Server. Шаги для настройки бэкапов PostgreSQL:

• Настроить Webdav Server

• Настроить webdav подключение на Ubuntu Server, где храниться БД

  а) Устанавливаем утилиту davfs2: sudo apt-get install davfs2

  б) Создаем папку /forwebdav в которую будем монтировать удаленный webdav каталог

  в) настраиваем параметры подключения в файле /etc/davfs2/secrets – добавляем
  в конце строку типа: http://192.168.1.111 user password

• Настроить автоматическое монтирование webdav тома в определенную директорию – для этого в /etc/fstab добавляем строчку:
  http://192.168.1.111:5005/webdav /forwebdav davfs noauto,user 0 0

  проверить настройку можно командой: mount /forwebdav

• Создать скрипт backup.sh и сделать его исполняемым, содержимое скрипта:
  PGPASSWORD="password" pg_dump -Fc -h localhost -U DBNAME > / forwebdav/ DBNAME -$(date +%Y-%m-%d-%H-%M).dump

• Настроить Cron на выполнение этого скрипта:
  crontab –e
0 1 * /script/ backup.sh

Файловые бэкапы

Первая задача, которая стояла перед нами — это бэкап файлов программного обеспечения, которое разрабатывают программисты.

У нас разработка ведется на C# и как такового деплоя нет — просто выкладываем финальную версию в общую папку, которая настроена в DFS и в этой папке располагается не только ПО, но и результаты работы ПО — всякие необходимые файлы, которые генерирует ПО и пользователи в процессе работы. На самом файловом сервере, где располагается папка с ПО включена версионность, чтобы можно было просмотреть состояние файлов в папке на определенную дату.

Саму папку бэкаплю на другой сервер бэкапов с помощью ПО DeltaCopy — это бесплатное ПО, это оболочка «Windows Friendly» вокруг программы Rsync.

Следующая задача — это бэкап файлов с 1С Документооборота и других конфигураций 1с. Здесь также использую ПО DeltaCopy.

Одно из наших веб-приложений, которое работает на Ubuntu Server хранит большое количество файлов, которое необходимо бэкапить – для этого монтирую на этот сервер удаленную webdav-директорию и с помощью rsync копирую файлы:
rsync -av /var/www/mysite.ru/myfiles/uploads /forwebdav/backupmysite/

Естественно, настраиваю для этого Cron.

3 задача — это бэкап файлов пользователей, здесь также включаю версионность на сервере где располагаются файлы. А бэкап их файлов делаю с помощью ПО DeltaCopy. Здесь добавлю, что с пользователями надо проводить разъяснительную работу на предмет, что можно хранить в корпоративном хранилище, а что нельзя. Хотя это мало помогает, все равно приходится искать «злодеев», которые забили все свободное место непонятно чем.

Вроде бы приняв такие меры и применив осторожность можно избежать статью 274УК. Описанные методы бесплатны, не идеальны, но работают.

Дополню: данные методы хоть и работают, но имеют существенные недостатки:

• rsync и шифровальщик могут уничтожить и оригинальные файлы и бэкап

• бэкап виртуальной машины через powershell - не гарантия работоспособности РК ВМ - нет проверки целостности...

• бэкап баз данных скриптами также не имеет проверки целостности

Специализированное ПО для создания резервных копий решает эти проблемы. Мы используем только Windows Backup - немного позже дополню статью информацией. Но а скрипты всегда полезны, это, прежде всего развитие...

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