Не будет преувеличением сказать, что отсутствие или неправильное резервное копирование данных может привести к значительным убыткам, а то и к полной потере бизнеса.
В этой статье я расскажу о своём опыте настройки резервного копирования данных в одном из SAAS-сервисов интернет-магазинов, а также почему было выбрано именно такое решение.
Статья будет полезна начинающим системным администраторам в компаниях со схожим профилем, когда нужно копировать данные production-серверов, серверов разработки, а также вспомогательных сервисов. При этом требуется безопасным образом хранить ежедневные, еженедельные, ежемесячные, полугодовые и годовые копии данных. О том, почему используется такой график копирования, мы тоже расскажем.
Как все начиналось
Когда-то очень давно, порядка 20 лет назад, весь SAAS-сервис состоял из одного сервера с двумя дисками, и на этом сервере работало около десятка интернет-магазинов.
Один сервер
На первом диске сервера была установлена ОС FreeBSD, Apache и MySQL. Там же находились каталоги с данными сайтов. Второй диск при этом использовался для хранения резервных копий данных, созданных при помощи панели ISPmanager версии 4. Дополнительно данные бэкапов закачивались на компьютер в офисе с помощью FileZilla и записывались на диски CD-R.
Все было хорошо до тех пор, пока первый из этих дисков не вышел из строя. Замена диска и последующая установка OS с восстановлением сайтов из резервной копии заняла около двух дней, и все это время сайты не работали.
Конечно, если бы диски были объединены в зеркальный RAID-массив (RAID-1), последствия выхода из строя одного диска не были бы так катастрофичны.
Однако сам по себе RAID-1 не заменяет резервного копирования данных, а только предотвращает останов сервиса при выходе из строя одного из дисков зеркала. В самом деле, если на рабочем диске какие-то данные удалили по ошибке, они тут же будут стерты и с зеркального диска.
Добавили второй сервер и RAID-1
После приобретения второго сервера на обоих серверах были созданы зеркальные массивы RAID-1. Также было настроено автоматическое резервное копирование данных с одного сервера на другой средствами панели ISPmanager.
С бэкапами стало немного лучше. Теперь даже при полном выходе из строя одного из серверов можно было скачать ночной бэкап с другого сервера и после ремонта отказавшего сервера восстановить работу магазинов.
В то же время примерно раз в неделю бэкапы закачивались в офис и записывались на диски CD-R на случай выхода из строя обоих серверов или катастрофы в дата-центре. Но это была довольно трудоемкая процедура.
Добавили серверы бэкапов
Полный хаос наступил, когда в дата-центре было установлено несколько серверов. Какое-то время данные бэкапов копировались между этими серверами (рис. 1, так делать не надо).
Схема работала и предотвращала потерю данных при выходе из строя какого-либо сервера, но настройка и контроль бэкапов превратился в ужас. В результате было принято решение приобрести выделенные серверы бэкапов.
Со временем количество серверов и объемы данных резервных копий росло, и пришлось установить второй сервер бэкапов в другом дата-центре (рис. 2).
Теперь появилась возможность копировать данные с серверов, расположенных в одном дата-центре, на сервер бэкапов, установленный в другом дата-центре (принадлежащем другой компании). Такая схема гарантировала сохранность данных при катастрофе в одном из них.
Написали свои скрипты для копирования данных
Через некоторое время пришло понимание, что нужно делать не только полные, но и инкрементные резервные копии данных. Оказалось, что иногда требуется восстанавливать долгосрочные данные бэкапов. Кроме того, необходимо как-то контролировать результат резервного копирования данных с помощью Zabbix.
Панель управления сервером ISPmanager позволяла организовать хранение данных бэкапов за несколько дней, однако были трудности с автоматизацией контроля результатов бэкапа. Кроме того, при изменении версии панели изменялся и формат хранения выгруженных данных.
Была попытка использовать Bacula, но это решение оказалось не слишком удобным и очень сильно нагружало хостинговые серверы. Поэтому от него решили отказаться.
В результате был разработан набор скриптов резервного копирования, который выполнял все необходимые функции. После копирования данных скрипты проверяли размер архивов, созданных на серверах бэкапов, сравнивая их с исходным размером на рабочих серверах.
Результат сравнения отправлялся системному администратору по электронной почте, а также в Zabbix. Как показала практика, такой контроль позволял обнаружить большинство проблем, возникающих при создании бэкапов.
Установили в офисе архивный сервер бэкапов
Теперь данные бэкапов автоматически записывались на серверы бэкапов, и это не требовало никакого участия системного администратора. Оставалось одно узкое место — закачка бэкапов на компьютер в офис и запись файлов на диски DVD-R (на CD-R данные уже не помещались).
Было приобретено и установлено в офисе устройство DNS-345 в качестве локального сервера бэкапов, куда можно вставить четыре диска, создав два зеркальных RAID-массива. Были написаны скрипты, которые закачивали данные с серверов бэкапа и сохраняли их на дисках этого сервера.
С помощью этих скриптов данные с серверов бэкапов загружались на диски архивного сервера бэкапов (рис. 3).
В итоге вместо утомительной ручной работы по загрузке бэкапов и их записи на DVD-R (куда данные уже не помещались) стало достаточно включить DNS-345 и запустить скрипт копирования бэкапов. После завершения копирования устройство выключалось.
Почему не облако
Если нужно сделать резервную копию данных, более конфиденциальных, чем фотки и видео из отпуска, едва ли стоит копировать их в облачное хранилище, принадлежащее другой компании. Может получиться так, что вы по тем или иным причинам потеряете доступ к облаку или ваши данные будут скомпрометированы. А ведь от сохранности бэкапов и недоступности их для посторонних лиц может зависеть ваш бизнес.
Кроме того, стоимость хранения данных в облаке может превышать стоимость аренды выделенных серверов для резервного копирования данных.
Из этих соображений было принято решение хранить данные на собственных серверах бэкапов.
Разработка плана резервного копирования данных
При разработке плана резервного копирования данных нужно сделать следующие шаги.
Понять, какие данные являются критическими и подлежат резервированию
В случае SAAS-сервиса интернет-магазинов это базы данных, файлы пользователей и заданий crontab, сертификаты SSL сайтов, файлы конфигурации OC хостинговых серверов.
Кроме того, необходимо хранить содержимое серверов разработчиков, данные GitLab, данные серверов VPN и различных дополнительных сервисов, необходимых для разработки и функционирования интернет-магазинов.
Определить срок хранения и расписание бэкапов
Для правильного определения срока хранения и расписания бэкапов важно понять, от каких проблем и ошибок бэкапы будут защищать SAAS-сервис или другую подобную систему. Например:
менеджер интернет-магазина по ошибке что-то удалил или изменил на сайте (товар, заказ, сезонную коллекцию или какие-нибудь настройки);
сотрудники службы поддержки, программисты или системные администраторы ошибочно удалили нужные файлы или данные из БД;
интернет-магазин закрылся, но потом решил возобновить работу;
в результате сбоя на сервере оказались повреждены таблицы базы данных или файлы;
возникла необходимость частичной или полной переустановки сервера.
По опыту, самой частой причиной восстановления данных является человеческий фактор. Система бэкапов должна быть разработана в первую очередь для ликвидации последствий этого фактора. Даже если файлы или базы были ошибочно удалены системным администратором. Да, системные администраторы тоже ошибаются.
При разработке расписания бэкапов приходится идти на различные компромиссы.
С одной стороны, бэкапы хорошо бы делать как можно чаще, и при этом хранить как можно дольше каждую копию. С другой стороны, объемы данных не позволяют запускать резервное копирование чаще одного раза в сутки.
При этом может потребоваться восстановить не только самый свежий бэкап, но и тот, что был сделан вчера, несколько дней, недель или месяцев назад. Бывают ситуации, что исчезновение данных было замечено не сразу, поэтому одного только ночного бэкапа совершенно недостаточно.
Если вы арендуете виртуальный хостинг или виртуальную машину, то провайдер может делать инкрементные бэкапы каждый день. При этом полная копия может сохраняться каждую неделю в течение месяца. Уточните у провайдера, сколько стоит такая услуга.
Но если провайдер хранит только одну ночную копию данных, а пропажа была обнаружена несколько дней назад, ничего восстановить из бэкапов провайдера уже не получится.
Кроме того, могут потребоваться бэкапы, сделанные несколько месяцев назад или даже прошлогодние.
В настоящий момент на серверах бэкапов SAAS-сервиса хранятся копии данных:
пять ежедневных;
две еженедельные;
одна ежемесячная
Практика показала, что такая схема позволяет быстро восстанавливать данные в самых распространенных случаях. А чаще всего нужны бэкапы за вчерашний день или за несколько прошедших дней.
Что касается долговременного хранения данных, то в офисе на архивном сервере бэкапов данные хранятся за следующие периоды:
три еженедельных;
две ежемесячные:
одна полугодовая;
одна годовая
Эти данные обычно требуются в тех случаях, когда нужно заново открыть закрывшийся ранее интернет-магазин, когда потребовалось восстановить удаленный ранее сезонный ассортимент или разобраться в той или иной ситуации, которая сложилась относительно давно.
Когда требования к сохранности данных серьезные и ежедневного бэкапа недостаточно, имеет смысл дополнительно организовать репликацию базы данных и файлов сайта на другой сервер. В этом случае у вас всегда будет актуальная копия данных, которая сохранится при выходе основного сервера из строя. Но репликация и создание отказоустойчивых решений — это тема для отдельной статьи.
Так как создание резервных копий и их запись на серверы бэкапов создают нагрузку на рабочие серверы, то хорошо бы запускать бэкапы в ночное время, когда посещаемость сайтов минимальна. Но тут появляется противоречие с тем, что ширина канала до сервера бэкапов ограничена, и обычно составляет всего 100 Мбит/c.
В результате приходится составлять расписание запуска бэкапов таким образом, чтобы сетевой интерфейс сервера бэкапов не был перегружен, особенно днем (рис. 4).
Сейчас в некоторых дата-центрах можно арендовать серверы с невыделенным каналом 1 Гбайт/c без дополнительной оплаты. Это предложение очень неплохо подходит для серверов бэкапов.
Выбрать метод резервного копирования
Известно, что можно выполнять разные виды резервного копирования данных, например полное или инкрементное.
Для серверов SAAS-сервиса было настроено как полное, так и инкрементное резервное копирование данных. Инкрементное копирование данных экономнее использует место на дисках. Оно используется на тех серверах, где нет дисков, специально выделенных для бэкапов.
Разработать процедуру восстановления данных
Как правило, если потребовались данные бэкапов, то они нужны очень срочно. Поэтому были разработаны инструкции, в которых описано расположение бэкапов для всех серверов и виртуальных машин. Также созданы инструкции по восстановлению бэкапов.
Время от времени эти инструкции проверяются на практике, так как приходится что-либо восстанавливать из бэкапов.
Периодически проверяйте резервные копии данных
Время от времени нужно проводить ревизию резервных копий и тестовое восстановление.
Как минимум нужно проверять существование файлов резервных копий и их размер, а для самых важных данных — выполнять их восстановление и проверку, например, на специально выделенном для этого сервере.
Если игнорировать эти процедуры, то может получиться так, что нужного бэкапа не окажется в самое неподходящее время.
Обновляйте план резервного копирования
Если ваш проект существует много лет, то в нем постоянно происходят те или иные изменения. Добавляются новые серверы или виртуальные машины, удаляются старые, изменяются требования к хранению данных и так далее.
Поэтому периодически обновляйте план резервного копирования, а также инструкции по восстановлению данных.
Выбор дисков для работы сайтов и для хранения бэкапов
Когда вы арендуете или приобретаете серверы, очень важно выбрать правильные диски для работы сайтов, а также для хранения данных бэкапов.
Рабочие серверы
Первое время на рабочие серверы SAAS-сервиса устанавливали три скоростных SAS-диска (15000 оборотов в секунду), подключенных к дисковому контроллеру LSI с резервной батарейкой, защищающей кэш-память контроллера. Два диска объединялись в зеркальный массив RAID-1, а третий оставался в горячем резерве.
Такая схема хорошо защищает от выхода из строя отдельных дисков, но с точки зрения создания бэкапов это не лучшее решение. Резервные копии приходится создавать на рабочих дисках, где не так уж много свободного места.
Гораздо удачнее оказался вариант, когда на сервере для работы использовался массив RAID-1 из SSD- или NVMe-дисков, а для создания резервных копий — тоже массив RAID-1, но из дисков SATA.
В этом случае SSD-диски обеспечивали необходимое быстродействие даже без контроллера дисков с кэшем и батарейкой, а диски SATA успешно брали на себя нагрузку по ежедневной записи большого объема данных.
Резервные копии, созданные на дисках SATA, каждую ночь копировались на сервер бэкапов.
Серверы бэкапов
Здесь нет особых требований к скорости работы, поэтому на сервер бэкапов можно установить диски SATA, объединив их в зеркальный RAID-массив. Также на этом сервере вам не потребуется мощный процессор и много оперативной памяти, поэтому можете взять недорогой вариант с большими дисками.
Архивный сервер бэкапов
Аналогично серверу бэкапов, для архивного сервера подойдут диски SATA, не требуется мощный процессор и много памяти.
На рис. 5 мы показали My Book World Edition II и DNS-345, которые можно использовать для хранения данных бэкапов относительно небольшого объема в офисе или дома.
Если вы думаете хранить архивы на дисках SSD, то учтите, что такие диски не рекомендуется оставлять надолго в выключенном состоянии — они могут потерять записанные данные.
Скрипты создания бэкапов на серверах
Для обеспечения работы системы бэкапов был подготовлен набор скриптов. Часть из них составлена на Bash, а часть — на Perl. Вы можете использовать любые языки программирования, но наши системные администраторы выбрали Bash и Perl, потому что так исторически сложилось.
Скрипт полного бэкапа сервера
Для создания локальных файлов бэкапа и их копирования на нужный сервер бэкапов на каждом сервере через crontab запускается скрипт server_full_backup.sh:
/bin/sh /home/admin/backup_scripts/iSYSBackup.sh
/bin/sh /home/admin/backup_scripts/iDBbackup.sh
/bin/sh /home/admin/backup_scripts/iFilesBackup.sh
/usr/bin/perl /home/admin/backup_scripts/BackupTransferZbx.pl $1 $2 $3
/usr/bin/perl /usr/local/bin/incbackup -config /usr/local/etc/rdiff_backup_config.ymlЭтот скрипт, в свою очередь, запускает скрипты копирования файлов конфигурации iSYSBackup.sh, баз данных iDBbackup.sh и файлов пользователей iFilesBackup.sh.
Когда все локальные файлы бэкапов будут созданы, они копируются на сервер бэкапов скриптом BackupTransferZbx.pl. Этот же скрипт отправляет результаты копирования в Zabbix.
Далее запускается скрипт создания инкрементных копий incbackup. Описание инкрементного копирования заслуживает отдельной статьи.
Копирование файлов конфигурации
Скрипт iSYSBackup.sh копирует в локальный каталог сервера файлы из каталогов /etc/, /usr/local/etc/, /var/spool/cron/crontabs (пакетные задания) и /var/www/httpd-cert (сертификаты сайтов):
#!/bin/sh
BACKUP_DIR="/raid/backups/admin_sys_files/"
BACKUP_FILE="3_Sys-`date +%Y-%m-%d`.tar"
LIFETIME=6
TAR="$(which tar)"
CHOWN="$(which chown)"
RM="$(which rm)"
MKDIR="$(which mkdir)"
FIND="$(which find)"
GZIP="$(which gzip)"
$TAR -cf $BACKUP_DIR$BACKUP_FILE /etc/
$TAR -rf $BACKUP_DIR$BACKUP_FILE /usr/local/etc
$TAR -rf $BACKUP_DIR$BACKUP_FILE /var/spool/cron/crontabs
$TAR -rf $BACKUP_DIR$BACKUP_FILE /var/www/httpd-cert
$RM $BACKUP_DIR$BACKUP_FILE.gz
$GZIP $BACKUP_DIR$BACKUP_FILE
$FIND $BACKUP_DIR -type f -mtime +$LIFETIME -exec $RM {} \;
exit 0Файлы резервных копий создаются в каталоге, заданным в переменной BACKUP_DIR, а имя файлов определяется маской из переменной BACKUP_FILE.
После завершения копирования удаляются файлы, созданные ранее LIFETIME дней.
Копирование файлов пользователей
Для копирования файлов пользователей создан скрипт iFilesBackup.sh:
#!/bin/sh
BACKUP_DIR="/raid/backups/"
BACKUP_FILE="admin-2_full-`date +%Y-%m-%d`.tar.gz"
LIFETIME=5
TAR="$(which tar)"
CHOWN="$(which chown)"
RM="$(which rm)"
MKDIR="$(which mkdir)"
FIND="$(which find)"
USERS_FROM_HOME="`find /home/ -mindepth 1 -maxdepth 1 -type d ! -name 'httpd-logs' ! -name 'nginx-logs' -printf '%f\n'`"
for usr in $USERS_FROM_HOME
do
$MKDIR -p "$BACKUP_DIR$usr"
echo $BACKUP_DIR$usr/$BACKUP_FILE /home/$usr/
$TAR -czf $BACKUP_DIR$usr/$BACKUP_FILE /home/$usr/
$FIND $BACKUP_DIR$usr/ -type f -mtime +$LIFETIME -exec $RM {} \;
done
exit 0Этот скрипт сканирует каталог /home/ и архивирует данные всех пользователей. При этом расположенные в каталоге /home/ подкаталоги httpd-logs и nginx-logs исключаются из копирования. Старые файлы резервных копий удаляются.
Копирование баз данных
Скрипт iDBbackup.sh выполняет резервное копирование баз данных при помощи утилиты mysqldump:
#!/bin/sh
PATH="$PATH:/usr/local/bin/:/usr/bin"
BACKUP_DIR="/raid/backups/admin_sys_db/"
BACKUP_FILE="1_SysDB-`date +%Y-%m-%d`.tar.gz"
LIFETIME=6
MDIR="mysql/"
MYSQL="$(which mysql)"
MYSQLDUMP="$(which mysqldump)"
TAR="$(which tar)"
CHOWN="$(which chown)"
RM="$(which rm)"
MKDIR="$(which mkdir)"
FIND="$(which find)"
DBS="$($MYSQL --defaults-extra-file='/raid/backups/credentials.cnf' -Bse 'show databases')"
$RM -rf $BACKUP_DIR$MDIR
$MKDIR -p $BACKUP_DIR$MDIR
for db in $DBS
do
echo $db
if [ $db != 'performance_schema' ] ; then
FILE=$BACKUP_DIR$MDIR$db.sql
$MYSQLDUMP --defaults-extra-file='/raid/backups/credentials.cnf' --opt --quote-names --single-transaction --events $db > $FILE
fi
done
$TAR -czf $BACKUP_DIR$BACKUP_FILE $BACKUP_DIR$MDIR
$RM -rf $BACKUP_DIR$MDIR
$FIND $BACKUP_DIR -type f -mtime +$LIFETIME -exec $RM {} \;
exit 0Получив управление, скрипт получает и сохраняет в переменной DBS список баз данных. Для выполнения команды «show databases» скрипт пользуется доступом из файла credentials.cnf:
[client]
host = localhost
user = root
password = ******Далее скрипт получает дампы баз данных, сохраняет их в каталоге $BACKUP_DIR$MDIR и удаляет старые файлы бэкапов.
Копирование файлов на сервер бэкапов
Для копирования созданных файлов на сервер бэкапов, а также для отправки результатов копирования в Zabbix используется скрипт BackupTransferZbx.pl:
#!/usr/bin/perl
use strict;
use Data::Dumper;
use ITMATRIX::BackupTransfer;
use ITMATRIX::Email;
use ITMATRIX::Mailer;
my $object = 'ITMATRIX::BackupTransfer'->new( config => '/backups/config.yml', test => 0, ftp_debug => 0 );
my $host_name = $object->get_config->{ local_host_name };
my $log = $object->export_log();
my $errors = $object->export_errors();
my $subject = "Backup $host_name";
if ($errors)
{
$subject .= " HAS ERRORS";
}
else
{
$subject .= " OK";
}
my $body = q();
if ($errors)
{
$body .= "Errors:<br>".$errors."<br><br>";
}
$body .= "LOG:<br>".$log;
my $email = 'ITMATRIX::Email'->new();
$email->set_email_params( to => ['admin@domain.ru'],
from_name => "backup transfer $host_name",
from_email => 'backup_transfer@domain.ru',
subject => $subject,
body => $body,
);
$email->set_local_send();
$email->set_content_type('html');
'ITMATRIX::Mailer'->new()->send($email);
# ========================================================
# Отправка результата копирования в Zabbix
# ========================================================
my $zabbix_sender_data_file = '';
my $debug = 0;
my $zabbix_sender;
my $zabbix_server_ip = $ARGV[0];
my $hostname = $ARGV[1];
if($ARGV[2] eq 'debug') { $debug = 1; } else { $debug = 0; }
if($^O eq 'linux')
{
$zabbix_sender = '/usr/bin/zabbix_sender';
$zabbix_sender_data_file = '/home/admin/backup_scripts/zabbix_data.txt';
}
else
{
print "\nUnsupported OS: $^O";
exit(1);
}
if ($debug)
{
print "zabbix_sender path: ".$zabbix_sender."\n".'OS: '.$^O."\n";
print "Zabbix server IP: ".$zabbix_server_ip.', Hostname: '.$hostname."\n";
}
# Prepare Zabbix Sender file
my $transferOK = 1;
if ($errors)
{
$transferOK = 0;
}
open(my $fh, '>', $zabbix_sender_data_file) or die "Не могу открыть '$zabbix_sender_data_file' $!";
print $fh $hostname." backup.transferOK ".$transferOK."\n";
close $fh;
my @zabbix_server_ip_array = split(',', $zabbix_server_ip);
foreach my $server_ip (@zabbix_server_ip_array)
{
my $trap_cmd = $zabbix_sender.' -vv -z '.$server_ip.' -i '.$zabbix_sender_data_file;
if ($debug) {
print "Trap cmd: ".$trap_cmd."\n";
};
my @trapout = ();
@trapout = split /\n/, `$trap_cmd`;
if ($debug) { print Dumper(\@trapout); }
}
exit(0);Если копирование завершилось с ошибкой, срабатывает триггер в Zabbix. Другой триггер сработает, если результаты резервного копирования не будут поступать каждые 24 часа.
Все действия по копированию файлов выполняет функция ITMATRIX::BackupTransfer:
my $object = 'ITMATRIX::BackupTransfer'->new(config => '/backups/config.yml', test => 0, ftp_debug => 0);В файле /backups/config.yml определены параметры копирования:
local_host_name: cs7
local_backup_dir: /raid/backups
copies:
day: 6
week: 3
month: 2
ftp:
ip: xxx.xxx.xxx.xxx
login: bcs7
password: *********
no_copy_backup_dir:
- user8
no_check_user:
- user9Здесь указывается имя сервера, локальный каталог с файлами бэкапов, график бэкапов, доступ FTP к серверу бэкапов, а также каталоги и пользователи, файлы бэкапов которых копировать не требуется.
Результаты копирования записываются в журнал и отправляются по электронной почте.
Полностью исходный текст модуля ITMATRIX::BackupTransfer можно посмотреть здесь.
Защита серверов бэкапов
Так как серверы бэкапов содержат важные и, возможно, конфиденциальные данные, их следует защитить от несанкционированного доступа.
Как минимум нужно сделать следующее:
настроить файрвол, ограничив доступ только с серверов, отправляющих бэкапы;
установить на серверы бэкапов сервис fail2ban для защиты от подбора паролей;
разрешить разработчикам и службе поддержки доступ к серверам бэкапов только через корпоративный VPN.
При необходимости можно также настроить шифрование дисков серверов бэкапов, чтобы затруднить получение данных, когда диски вынимаются из сервера.
Резервное копирование данных разработчиков
Для хранения результатов разработки на SAAS-сервисе используются собственные серверы GitLab. При этом каждый день создаются резервные копии данных GitLab, а затем сохраняются на выделенных серверах резервных копий.
Резервное копирование Gitlab выполняет немного модифицированный скрипт iFilesBackup.sh:
#!/bin/sh
BACKUP_DIR="/backups/"
BACKUP_FILE="admin-2_full-`date +%Y-%m-%d`.tar.gz"
LIFETIME=1
TAR="$(which tar)"
CHOWN="$(which chown)"
RM="$(which rm)"
MKDIR="$(which mkdir)"
FIND="$(which find)"
echo "Gitlab Backup..."
rm -Rfv /home/git-backup/*.tar.gz
/opt/gitlab/bin/gitlab-rake gitlab:backup:create CRON=1
echo "Store gitlab backup into the git-backup home dir..."
GITLAB_DB_BACKUP="gitlab_db_backup-`date +%Y-%m-%d`.tar.gz"
$TAR -czf /home/git-backup/$GITLAB_DB_BACKUP /var/opt/gitlab/backups/
echo "Other users Backup..."
USERS_FROM_HOME="`find /home/ -mindepth 1 -maxdepth 1 -type d ! -name 'httpd-logs' ! -name 'nginx-logs' -printf '%f\n'`"
for usr in $USERS_FROM_HOME
do
$MKDIR -p "$BACKUP_DIR$usr"
echo $BACKUP_DIR$usr/$BACKUP_FILE /home/$usr/
$TAR -czf $BACKUP_DIR$usr/$BACKUP_FILE /home/$usr/
$FIND $BACKUP_DIR$usr/ -type f ! -newer $BACKUP_DIR$usr/$BACKUP_FILE ! -name "$BACKUP_FILE" -delete
done
$FIND $BACKUP_DIR$usr/ -type f ! -newer $BACKUP_DIR$usr/$BACKUP_FILE ! -name "$BACKUP_FILE" -delete
exit 0В самом начале скрипт делает резервную копию Gitlab с помощью утилиты gitlab-rake. Далее файл бэкапа упаковывается и копируется в домашний каталог пользователя git-backup.
После этого скрипт iFilesBackup.sh выполняет резервное копирование файлов всех пользователей, как это делается на других серверах.
Настройка бэкапа для Gitlab Omnibus описана здесь. Также вам пригодится документация по восстановлению бэкапа Gitlab.
Автор статьи: Александр Фролов.
НЛО прилетело и оставило здесь промокод для читателей нашего блога:
— 15% на все тарифы VDS (кроме тарифа Прогрев) — HABRFIRSTVDS.
