Pull to refresh

Информатизация вуза. Бэкапы виртуальных машин, баз данных, файлов

Level of difficultyEasy
Reading time12 min
Views6.4K

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

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

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

Статья 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) Enable-WSManCredSSP -Role Server -Force

4) Импорт рег-файла, который создаст ветку реестра: 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.

Можно настроить оповещение на электронную почту - для этого необходимо настроить компонент DataBase Mail, создать оператор и настроить оповещения в задании.

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

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

#папки, в которых нельзя удалять 
$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.

DeltaCopy - это клиент-серверное приложение, сервер работает как служба. Службу необходимо запускать от имени пользователя (администратора), под которым Вы производите все манипуляции с синхронизированной папкой, это позволит избежать ошибку - "отказано в доступе" при работе с синхронизированной папкой, например при ее архивации.

Также настраивайте уведомления на почту на DeltaCopy клиенте, что понимать работает синхронизация или нет.

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

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

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

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

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

param($Source, $Target, $to, $from, $mailserver, $R)

function DelOldFolders ($Paths, $R, $LOG){

   #проверка есть ли папка для бекапов
   if (-not (Test-Path -Path $Paths)) {
    throw "$Paths not found"
}
   #количество подпапок в папке
   $foldersCount= Get-ChildItem $Paths | Measure-Object | %{$_.Count}
   write "количество бекапов  - $foldersCount !!!!!!!!!!!!!!!!!!!!!!!!"
   #если количество подпапок меньше чем необходимое количество бекапов то выоходим из цикла - удалять ничего не надо
   if($foldersCount -le $R){
       write "количество бекапов мало - $foldersCount - выходим!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!"
       return
   }
   else{
  # пока количество папок не равно необходимому количеству бекапов 
   While ($foldersCount -ne $R){
    #список папок
    $folders = dir $Paths
    write "colpap $foldersCount"
    #переменная для хранения даты
    $datetime = get-date
     #находим папку с самой старой датой
     foreach ($p in $folders ){
            if ($datetime -gt $p.LastWriteTime){
                $datetime= $p.LastWriteTime
                Write $datetime
            }
            
     }
     #ищем самую старую папку и удаляем
    
     foreach ($s in $folders ){
                if ($datetime -eq $s.LastWriteTime){
                    cd $Paths
                    Write "Удаляю $s   дата $datetime ___________________________________"
                    Write "Удаляю $s   дата $datetime ___________________________________" | out-file  $LOG -append
                    rm $s -recurse
                }
            }
     #обновляем значение переменной - количество подпапок      
     $foldersCount= Get-ChildItem $Paths | Measure-Object | %{$_.Count}
     } 
}
   }



try{
$7zipPath = "$env:ProgramFiles\7-Zip\7z.exe"
if (-not (Test-Path -Path $7zipPath -PathType Leaf)) {
    throw "7 zip file '$7zipPath' not found"
}
Set-Alias Start-SevenZip $7zipPath
$starttime=get-date
write "$starttime начало бекапа"
$curdate = (get-date -format "dd.MM.yy.HH.mm.ss")
#удаляем старые бэкапы
DelOldFolders -Paths $Target -R $R -LOG "G:\7z_backup\log.txt"
#создаем архив
Start-SevenZip a -mx=0 -r0 -ssw $Target\$curdate.zip $Source
$endtime=get-date
#вычисляем длительность создания архива
$duration= $duration= [math]::Round(($endtime - $starttime).TotalMinutes, 2)
write "$endtime конец бекапа"
#проверяем создался ли файл с архифвом
if (-not (Test-Path -Path $Target\$curdate.zip)) {
    throw "архив не создан"
}
#вычисляем размер архива
$FolderSize = [math]::Round((Get-ChildItem $Target\$curdate.zip -recurse -Force | Measure-Object -Property Length -Sum).Sum / 1Gb, 2)
#отправляем на почту сообщение 
Send-MailMessage -From $from -To $to -Subject "$(get-date -format "dd.MM.yy.HH.mm.ss") Backup $Source  OK ($duration min, $FolderSize Gb)" -Body "Backup $Source OK - Duration $duration min, $FolderSize Gb" –SmtpServer $mailserver -Encoding 'UTF8'
}
catch{
#обрабатываем ошибки
Send-MailMessage -From $from -To $to -Subject "$(get-date -format "dd.MM.yy.HH.mm.ss") Backup $Source ERROR" -Body "Backup $Source error - $_" –SmtpServer $mailserver -Encoding 'UTF8'
write $_
}

Чтобы запустить скрипт используем команду:

PowerShell.exe -NoLogo -NoProfile -File c:\ps\BackuPFolder.ps1 -Source G:\Backup\source1 -Target G:\7z_backup\source1 -to it-events@example.ru -from it-events@example.ru -mailserver example.ru -R 4

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

Примерная схема бэкапов с помощью rsync такая:

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

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

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

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

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

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

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

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

Прошу, напишите в комментариях как Вы решаете проблему РК и какое ПО для РК Вы используете, какие подходы, какую литературу. Всем спасибо, всем добра!

Tags:
Hubs:
Total votes 4: ↑4 and ↓0+4
Comments24

Articles