Восстанавливаем сайт из резервной копии ISP Manager

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

Мы справились с реанимацией сайтов за 3 часа. Если бы у нас была эта инструкция, «подняли» бы их быстрее. Предполагаем, что наш опыт будет полезен коллегам в экстренных ситуациях.

Итак, на упавшем сервере стоит/стояла панель ISP Manager, инкрементальная резервная копия сохраняется каждый день во внешнее облако. Инкрементальность резервной копии заключается в том, что раз в неделю делается полная резервная копия пользователя на сервере (в том числе и сайтов), а в течение недели изменения дописываются в последующие ежедневные копии.

Казалось, все хорошо – резервная копия есть, выполнена в ISP Manager и сайты будут развернуты на другом сервере, где есть ISP Manager.

Попытка #1. Пытаемся сделать импорт пользователя через ISP

1. Вкладка импорта пользователей в ISP Manager 5.

 Это не работает. 

1. Пункты: «URL архива», «из панели управления ISPmanager 5 (через rsync)», «из панели управления ISPmanager 5 (через backup)» отбрасываем, т.к. сервер-источник отключен.
2. Пункты: «из локального архива ISPmanager 4» и «из панели управления ISPmanager 4» также не подходят, т.к. мы работаем с последней версии ISP 5.
3. Остаются только пункты: «загрузить архив» и «из локального архива или каталога». По сути это одно и тоже, только в первом случае мы сразу загружаем архив резервной копии прямо с нашего компьютера, а во втором предварительно загружаем архив в определенную папку на принимающем сервере.

НО чтобы мы не делали у нас не получалось восстановить архив.

В каждой архивной версии содержится три и более файла:

• 2020-02-11.user_name.info – содержит информацию о текущем архиве, об этом чуть ниже в пункте 2 «Ручное извлечение архивной версии сайта».
• 2020-02-11.user_name.tgz – содержит полный перечень файлов, входящих в архив.
• F2020-02-11.user_name.tgz – собственно, архив всех файлов, базы данных и других данных пользователя, неполная версия – инкрементальная вместо буквы F в начале имеет букву I.

В случае если архив занимает более 100 Мб, то он дробится на части:

• F2020-02-16. user_name.tgz.part1
• F2020-02-16. user_name.tgz.part2
• F2020-02-16. user_name.tgz.partN

При попытках загрузить каждый файл по отдельности или загрузить все 3 файла вместе в архиве (в случае если сайт небольшой) – мы получали ошибку вида:

Хотя версия ISP донора и версия ISP акцептора совпадают: ISPmanager Lite 5.232.2.

А в случае если мы грузим большую архивную версию сайта, например, сайт размером ~25 Гб, то загрузка/распаковка зависала на 100% и дальше не двигалась.

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

Попытка #2. Извлекаем резервную копию сайта вручную из backup ISP

Особенно с большими сайтами.

1. Сначала открываем *.info – файл последней свежей версии архива. Его содержание примерно такое:

   base= user_name/2020-01-05/F2020-01-05.user_name.tgz
   created=2020-01-10 03:17:17
   duration=38
   finished=2020-01-10 03:17:55
   last-slice= user_name/2020-01-10/I2020-01-10.user_name.tgz
   type=incremental

   Это означает, что перед нами инкрементальная версия архива сайта (т.е. только лишь зафиксированные изменения, а не полностью весь архив пользователя). На это указывает параметр

   type=incremental

   (для полной версии архива мы бы увидели: type=full), а параметр

   base= user_name/2020-01-05/F2020-01-05.user_name.tgz

   указывает нам, где можно найти свежую версию архива со всеми файлами от которой можно будет отталкиваться.

2. Скачиваем базовую и инкрементальные версии архива до ближайшей к нам дате.
3. Т.к. сайт большой, то базовая версия архива содержит 251 часть и мы имеем множество файлов, оканчивающихся на (где N – порядковый номер архивной части). Чтобы объединить все архивы в один, можно воспользоваться стандартной консольной утилитой на *Unix-системах – побитное склеивание файлов (MAC/Linux — устройства):

   cat ./F2020-02-11.user_name.tgz.part1 ./F2020-02-11.user_name.tgz.part2 > tar -xz

   на PC можно использовать , выполнив команду «Собрать файл» в пункте меню «Файлы»:

   

4. Сборка даст единый файл вида , разархивировав который, получим файл вида , который также необходимо разархивировать.
5. В корне распакованных файлов будет две папки .system – где содержатся все базы данных, закрепленные за текущим пользователем, и папка внутри которой по пути содержатся файлы сайта.
6. Т.к. базовая версия архива не является самой свежей, то необходимо распаковать остальные инкрементальные архивные части и добавить их в базовую версию, переписав изменённые файлы.

Важно: резервные копии баз данных не создают инкрементальных частей – каждый раз база данных архивируется полностью, поэтому при ручном восстановлении базы данных достаточно распаковать последний выполненный архив системой ISP Manager.

Бонус! Распаковка зашифрованного архива

Если Вам «исключительно» повезло и Ваша резервная копия зашифрована, то предстоит сделать следующее:

1. Выполнить расшифровку каждого файла в отдельности в *Unix-системе (адекватного метода расшифровки в Windows-системах мы не нашли):

   openssl enc -aes-256-cbc -d -in ./I2020-02-11.user_name.tgz.aes.part1 -out ./I2020-02-11.user_name.tgz.part1 -pass pass:********

2. Побитно склеить каждый файл:

   cat ./I2020-02-11.user_name.tgz.part1 ./F2020-02-11.user_name.tgz.part2 > ./I2020-02-11.user_name.tgz

3. И собственно произвести распаковку архива.

В итоге

Бонусный вариант нам не достался – архивы не были зашифрованы, поэтому мы за 30 минут выкачали все необходимые части архива, собрали их в один, распаковали и развернули на новом сервере. Сменили A-записи на NS-серверах Yandex и через 15 минут сайты начали открываться по новому месту прописки. Ура!

UPD. С момента падения сервера прошла неделя, но вразумительного ответа от хостинг-компании нет: сервер так и не работает. Вскоре выяснилось, что сервер отключен за неуплату со стороны более крупной хостинг компании, у которой наш «хостинг» брал их в аренду.

В ISPmanager реализована система резервного копирования, построенная на основе ISPtar.

Что нового

Основные отличия от предыдущей реализации:

• каждый пользователь резервируется отдельно;
• как и в DAR-версии нет сложной системы фильтров. Оставлена возможность для администратора сервера исключать из резервной копии файлы, каталоги, базы данных (по умолчанию делается резервная копия всех данных пользователя) или исключать из резервного копирования выбранного пользователя;
• хранилище теперь может быть только одно. Но вы можете легко и быстро переключаться между хранилищами. В этом случае вы теряете доступ к одним резервным копиям (первого хранилища) и получаете доступ к резервным копиям второго хранилища;
• резервное копирование по умолчанию делается ежедневно. Первая резервная копия за неделю (неделя начинается с воскресенья) — полная, остальные — дифференциальные. Вы можете изменить график резервного копирования, изменив настройки планировщика (cron);
• резервное копирование отключенного пользователя делается один раз после его отключения;
• добавлена возможность ограничить общий объем резервных копий. При достижении данного ограничения система начнет удалять наиболее старые резервные копии. При этом, если это возможно, будет сохраняться одинаковое количество ежедневных и еженедельных копий;
• если общий объем резервных копий не ограничен, а на хранилище закончится место, система предпримет попытку освободить необходимое количество, удаляя наиболее старые резервные копии;
• общее количество хранимых резервных копий: 14 копий — 7 полных еженедельных и 7 дифференциальных ежедневных. Данное ограничение может быть изменено через параметр BackupCountLimit конфигурационного файла etc/ispmgr.conf.
• добавлена возможность указывать количество полных и ежедневных(дифференциальных) резервных копий:

Минимальное рекомендуемое значение параметра BackupCountLimit 2:2. В этом случае будет делаться 2 полных и 2 ежедневных(дифференциальных) копий.

• У пользователя появилась возможность скачать свою резервную копию, чтобы в последствии самостоятельно залить её на тот же или другой сервер.

Использование ISPtar позволяет реализовать ряд существенных улучшений:

• резервная копия разбивается на небольшие тома (по умолчанию 100Мб), что позволяет при частичном восстановлении существенно сократить время ожидания. А также сокращает количество необходимого свободного пространства на диске, которое требуется при создании и частичном извлечении из резервной копии
• Не сжимать некоторые типы файлов. Это позволяет существенно сократить затраты ресурсов ЦП при резервном копировании. Выключить сжатие для файлов с определёнными расширениями через файл etc/isptar.conf;
• Файлы из резервных копий могут быть извлечены без использования ISPmanager при помощи стандартных консольных приложений (подробности).

Настройка модуля

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

Приоритетами запуска можно управлять с помощью утилит nice и ionice. Приоритеты указываются в конфигурационном файле etc/ispmgr.conf параметром BackupCommandPrefix имеющим значение по умолчанию nice -n 10 ionice -c2 -n7.

Ограничение размера хранилища

Это поле позволяет задать максимальный размер, занимаемый резервными копиями на хранилище. При первом подключении локального хранилища будет автоматически выставлено ограничение в 50% от свободного места на разделе, содержащем директорию хранилища, это значение можно изменить. Также с этой версии добавлена защита от переполнения диска локального хранилища: при закачке каждой части в локальное хранилище система проверяет насколько заполнен диск и, если осталось доступно для пользователя менее 5% диска, система пытается удалить старые архивы для освобождения места. Если место освободить не получилось, резервирование закончится с подобной ошибкой в журнале:

backup DEBUG backup2_storage.cpp:119 Available limit with restriction 95 pct '0' mib
backup DEBUG backup2_storage.cpp:120 File size '54' mib
main DEBUG backup2_cp2_server.cpp:354 m_read = 'RELEASE 56686365'
main ERROR Upload failed
libmgr ERROR Error: Type: 'Cant split slices' Object: ' ' Value: 'Part name prefix missed for part ' '

Сканирование хранилища

Сканирование хранилища происходит в момент подключения к новому типу хранилища или переключения директории внутри подключенного хранилища.

Первое резервное копирование после смены директории хранилища сформирует полную копию, вне зависимости от наличия полных копий за предыдущие дни.

Просмотр старой версии файла

Перенос данных от провайдера к провайдеру

Резервные копии можно перенести с другого сервера. Для этого в списке резервных копий нужно нажать на кнопку «Импорт» тип источника, указать значение источника и нажать «Ок». Импортировать можно из версий Lite, Pro, Host в Business и наоборот.

В ISPmanager Lite, Pro, Host вы можете импортировать архивы из cPanel.

Полное восстановление пользователя

Исключение файлов и баз из резервного копирования

Задать список исключаемых файлов можно в настройках модуля резервного копирования. Пути задаются относительно домашнего каталога пользователя, например data/.filemgr-tmp. В фильтрах файлов можно использовать регулярные выражения(*). Указанные файлы не будут участвовать в процессе резервного копирования. В поле ниже можно исключить базы. Их нужно указывать в формате полное имя базы в отдельной строке.

Как изменить время запуска резервного копирования

По умолчанию резервное копирование делается ежедневно. Для ISPmanager Lite, Pro, Host можно изменить время запуска резервного копирования для задания ISPmanager backup task в модуле Планировщик. Задание в кроне выглядит следующим образом:

0 3 *	/usr/local/mgr5/sbin/cron-ispmgr sbin/backup2 >/dev/null 2>&1

Как ограничить время резервного копирования

Задать временной диапазон, когда должно выполняться резервное копирование, можно через параметр (BackupTimeInterval). Например: BackupTimeInterval 03:00:00-06:00:00 указывает, что резервное копирование должно проводиться с 3х до 6 часов ночи. Резервное копирование отдельного пользователя прерываться не будет. Если система не успеет скопировать всех пользователей в указанный промежуток времени, резервное копирование оставшихся пользователей будет продолжено на следующий день. При этом новых копий за этот день создаваться не будет.

Например: в понедельник 14.09.2015 мы успели скопировать 10 пользователей из 15. Значит, во вторник будут скопированы оставшиеся 5, а следующая резервная копия для всех пользователей будет сделана уже в только в среду 16.09.2015. Резервные копии всех пользователей будут иметь дату 14.09.2015, несмотря на то, что часть пользователей будет скопирована только 15.09.2015

Как освободить место в хранилище

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

Как ускорить процесс резервного копирования

При необходимости скопировать большой объем данных, вы можете изменить приоритет резервного копирования в конфигурационном файле etc/ispmgr.conf, за который отвечает параметр BackupCommandPrefix. По умолчанию значение параметра nice -n 10 ionice -c2 -n7.

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

ionice используется для получения и установки класса и приоритета процесса. Подробности смотрите здесь.

Служебные файлы резервной копии

Файл с расширением tgz хранит данные о файлах резервной копии.

Файл с расширением info хранит информацию о дате создания, имени последнего файла копии, размере и типе бэкапа.

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

Ограничение кол-ва резервных копий

Общее кол-во хранимых резервных копий для каждого из пользователей регулируется параметром BackupCountLimit в etc/ispmgr.conf.

Нечётное количество хранимых резервных копий

Если параметр BackupCountLimit имеет нечетное значение, например 15, то будет 8 полных и 7 ежедневных дифференциальных резервных копий. При превышении лимита будет удаляться в первую очередь ежедневная дифференциальная резервная копия. То есть, количество полных резервных копий и дифференциальных все равно будет стремиться к равному соотношению, но полных копий будет на одну больше.

Объекты исключенные из резервного копирования

По техническим причинам до версии 5.65 были исключены из резервного копирования сортировщики почтовых ящиков.

Как часто можно сделать новую резервную копию

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

Резервная копия пользователя

Для пользователя доступно создание одной резервной копии независимо от расписания, установленного через планировщик. Создать такую копию можно кнопкой «Новый» в списке резервных копий под пользователем панели. Такая же копия появляется в списке копий при импорте пользователя из архива *.tar.gz, который создается при скачивании резервной копии из панели. Повторное создание пользовательской резервной копии или импорт пользователя из архива *.tar.gz заменит существующую пользовательскую копию.

Резервная копия удаленного пользователя

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

Соотношение полных и ежедневных резервных копий

При первом запуске резервного копирования создается полная резервная копия. В последующие дни, если день недели не воскресенье, создаются ежедневные дифференциальные резервные копии. В воскресенье в любом случае создается полная резервная копия. В первые 14 дней получится соотношение 3 полных и 11 дифференциальных. По прошествии 14 дней начнут удаляться в первую очередь самые старые дифференциальные резервные копии. После того как у полной резервной копии не останется дифференциальных частей, она будет удалена. Следовательно, соотношение 7 полных и 7 дифференциальных резервных копий будет достигнуто приблизительно через 2 месяца.

Удаление резервных копий

Автоматическое

Автоматическое удаление наиболее старых незаблокированных резервных копий происходит

• при достижении лимита на размер хранилища,
• при достижении 95% заполнения раздела диска (для локального хранилища),
• при достижении кол-ва копий отдельного пользователя (BackupCountLimit), удаляется именно старый бэкап пользователя, превысившего лимит.

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

Ручное

Под администратором в списке резервных копий доступна кнопка «Удалить».

Для того, чтобы удалить резервную копию вручную, необходимо перейти в директорию /usr/local/mgr5, задать корректно переменную окружения BACKUP_TOKEN и выполнить команду sbin/backup2_cp —delete указав путь к info файлу резервной копии. Значение токена хранится в etc/ispmgr.conf в параметре BackupToken.

BACKUP_TOKEN="type=local;url=/var/backups/";sbin/backup2_cp --delete var/backup/ispmgr/2015-09-08.username.info

BACKUP_TOKEN="password=qwerty12345;type=ftp;url=[ftp://backup5.reserv.net;username=ftpuser23|ftp://backup5.reserv.net;username=ftpuser23] "; ls -1 var/backup/ispmgr/*username.info | xargs -I {} sbin/backup2_cp --delete {}

Пример удаления всех резервных копий в локальном хранилище:

BACKUP_TOKEN="type=local;url=/var/backups/";ls -1 var/backup/ispmgr/*.info | xargs -I {} sbin/backup2_cp --delete {}

Как изменить размер тома резервной копии

Изменить размер тома резервной копии через конфигурационный файл etc/ispmgr.conf.

Пример установки размера резервной копии 30 мегабайт

Восстановление/скачивание файла/базы данных/почтового ящика

Резервирование системных данных

Эти архивы не доступны из интерфейса панели, т.к. работать с ними нужно крайне редко.

Чтобы восстановить данные, нужно перейти в хранилище (например /var/backup). Выбрать файл архива корневого пользователя (обычно, root) за нужную дату и посмотреть содержимое архива командами:

/usr/local/mgr5/sbin/isptar -l F2015-09-16.root.tgz
tar -tf F2015-09-16.root.tgz

После, выбранный файл извлечь:

Пример извлечения файла ispmgr.root.dashboard.xml:

tar -zxvf F2015-09-16.root.tgz usr/local/mgr5/var/userconf/ispmgr.root.dashboard.xml

Сколько нужно места для работы резервного копирования

На сервере

Временная директория панели: по умолчанию /usr/local/mgr5/tmp Системная директория панели: по умолчанию /usr/local/mgr5/var/backup/ispmgr Размер одной части архива: по умолчанию 100Мб, меняется через опцию BackupSliceSize

При работе с нелокальным хранилищем:

В пользовательской дисковой квоте

Пользователю нужно иметь места как минимум на 1 часть бэкапа (по умолчанию 100Мб), это нужно потому, что архивация выполняется с правами пользователя и часть архива до заливки на хранилище принадлежит пользователю. Сделано так из соображений безопасности.

Как изменить временную директорию

Если вам крайне необходимо изменить временную директорию, остановите все процессы панели, скопируйте директорию /usr/local/mgr5/var/backup/ispmgr и примонтируйте нужный раздел средствами операционной системы в /usr/local/mgr5/var/backup/ispmgr. Это обычно делается так:

mount --bind /нужный/раздел /usr/local/mgr5/var/backup/ispmgr

На данный момент резервное копирование после изменения пути до временной директории не всегда работает корректно. Не рекомендуется использовать описанный ниже параметр:

Если утилита killall отсутствует, то выполнить:

/usr/local/mgr5/sbin/mgrctl -m ispmgr exit

Включение подробного журналирования

Чтобы увидеть все подробности работы новой системы резервного копирования в журналах панели нужно добавить следующие строки в etc/debug.conf:

backup2.* 9
backup2_import.* 9
backup2_download.* 9
backup2_cp.* 9
restore2.* 9
backup2_cgi.* 9
backup2_conv.* 9
backup2_system.* 9

и завершить работу панели командой killall core в SSH-консоли.

После чего можно включить вывод всех журналов резервного копирования так:

tail -f /usr/local/mgr5/var/backup2*log /usr/local/mgr5/var/restore2.log

Ручной запуск резервного копирования

За текущую дату

cd /usr/local/mgr5 && ./sbin/backup2 &

За определенную дату

Будьте осторожны с указанием даты далеко в будущем (больше чем BackupCountLimit/2 недель)! Если сделать копию в будущем и ещё одну с датой больше предыдущей, все копии за настоящее время могут быть удалены системой контроля размера резервных копий (даже если в копии за будущее не будет каких-то пользователей).

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

cd /usr/local/mgr5 && ./sbin/backup2 --date 2016-05-01 &

За определенную дату определенного пользователя

Будьте осторожны с указанием даты далеко в будущем (больше чем BackupCountLimit/2 недель)! Если сделать копию в будущем и ещё одну с датой больше предыдущей, все копии за настоящее время могут быть удалены системой контроля размера резервных копий (даже если в копии за будущее не будет каких-то пользователей).

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

cd /usr/local/mgr5 && ./sbin/backup2 --date 2016-05-01 user1 &

Ручная распаковка данных

Если у вас нет возможности восстановить данные через панель управления, но есть файлы из хранилища такого вида:

F2016-11-02.user.tgz.part1
F2016-11-02.user.tgz.part2

Вы можете склеить их обратно в архив так:

Команда для Unix (Linux/FreeBSD/MacOS):

cat F2016-11-02.user.tgz.part1 F2016-11-02.user.tgz.part2 > F2016-11-02.user.tgz

Команда для Windows:

copy /b F2016-11-02.user.tgz.part1 + /b F2016-11-02.user.tgz.part2 F2016-11-02.user.tgz

FAQ

Удаляются уже сделанные резервные копии

Возможна ситуация, при которой уже сделанные резервные копии внезапно удаляются из хранилища. При получении таймаута в 15 минут при FTP хранилище система резервного копирования считает, что кончилось место и удаляет наименее значимый бэкап из старых.

Файлы пользователей не включаются в резервную копию

GoogleDrive. Удаление директории в которую подключено резервное копирование в корзину

При необходимости удалить директорию в хранилище GoogleDrive, сначала необходимо отключить резервное копирование в ISPmanager, иначе поведение резервного копирование будет непредсказуемым.

В ISPmanager реализована новая система резервного копирования, построенная на основе ISPtar.

В ISPmanager Business эта система даст выбор администратору между версией с настройкой планов и сложных фильтров и упрощённой версией с одним планом и минимумом настроек.

Что нового

Основные отличия от предыдущей реализации:

• Каждый пользователь резервируется отдельно
• Как и в DAR-версии нет сложной системы фильтров. Оставлена возможность для администратора сервера исключать из резервной копии файлы, каталоги, базы данных (по умолчанию делается резервная копия всех данных пользователя) или исключать из резервного копирования выбранного пользователя
• Хранилище теперь может быть только одно. Но вы можете легко и быстро переключаться между хранилищами. В этом случае вы теряете доступ к одним резервным копиям (первого хранилища) и получаете доступ к резервным копиям второго хранилища
• Резервное копирование по умолчанию делается ежедневно. Первая резервная копия за неделю (неделя начинается с воскресенья) — полная, остальные — дифференциальные. Вы можете изменить график резервного копирования, изменив настройки планировщика (cron)
• Резервное копирование отключенного пользователя делается один раз после его отключения
• Добавлена возможность ограничить общий объем резервных копий. При достижении данного ограничения система начнет удалять наиболее старые резервные копии. При этом, если это возможно, будет сохраняться одинаковое количество ежедневных и еженедельных копий
• Если общий объем резервных копий не ограничен, а на хранилище закончится место, система предпримет попытку освободить необходимое количество, удаляя наиболее старые резервные копии.
• Общее количество хранимых резервных копий: 14 копий — 7 полных еженедельных и 7 дифференциальных ежедневных. Данное ограничение может быть изменено через параметр BackupCountLimit конфигурационного файла etc/ispmgr.conf.
• Добавлена возможность указывать количество полных и ежедневных(дифференциальных) резервных копий:

Минимальное рекомендуемое значение параметра BackupCountLimit 2:2. В этом случае будет делаться 2 полных и 2 ежедневных(дифференциальных) копий.

• У пользователя появилась возможность скачать свою резервную копию, чтобы в последствии самостоятельно залить её на тот же или другой сервер.

Использование ISPtar позволяет реализовать ряд существенных улучшений:

• Резервная копия разбивается на небольшие тома (по умолчанию 100Мб), что позволяет при частичном восстановлении существенно сократить время ожидания. А также сокращает количество необходимого свободного пространства на диске, которое требуется при создании и частичном извлечении из резервной копии
• Не сжимать некоторые типы файлов. Это позволяет существенно сократить затраты ресурсов ЦП при резервном копировании. Выключить сжатие для файлов с определёнными расширениями через файл etc/isptar.conf
• Файлы из резервных копий могут быть извлечены без использования ISPmanager при помощи стандартных консольных приложений (подробности )

Настройка модуля

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

Приоритетами запуска можно управлять с помощью утилит nice и ionice. Приоритеты указываются в конфигурационном файле etc/ispmgr.conf параметром BackupCommandPrefix имеющим значение по умолчанию nice -n 10 ionice -c2 -n7.

Ограничение размера хранилища

Это поле позволяет задать максимальный размер, занимаемый резервными копиями на хранилище. При первом подключении локального хранилища начиная с версии панели 5.63 будет автоматически выставлено ограничение в 50% от свободного места на разделе, содержащем директорию хранилища, это значение можно изменить. Также с этой версии добавлена защита от переполнения диска локального хранилища: при закачке каждой части в локальное хранилище система проверяет насколько заполнен диск и, если осталось доступно для пользователя менее 5% диска, система пытается удалить старые архивы для освобождения места. Если место освободить не получилось, резервирование закончится с подобной ошибкой в журнале:

backup DEBUG backup2_storage.cpp:119 Available limit with restriction 95 pct '0' mib
backup DEBUG backup2_storage.cpp:120 File size '54' mib
main DEBUG backup2_cp2_server.cpp:354 m_read = 'RELEASE 56686365
main ERROR Upload failed
libmgr ERROR Error: Type: 'Cant split slices' Object: ' ' Value: 'Part name prefix missed for part ' '

Сканирование хранилища

Сканирование хранилища происходит в момент подключения к новому типу хранилища или переключения директории внутри подключенного хранилища.

Первое резервное копирование после смены директории хранилища сформирует полную копию, вне зависимости от наличия полных копий за предыдущие дни.

Просмотр старой версии файла

Перенос данных от провайдера к провайдеру

Резервные копии можно перенести с другого сервера. Для этого в списке резервных копий нужно нажать на кнопку «Импорт» тип источника, указать значение источника и нажать «Ок». Импортировать можно из Lite (Pro, Host) в Business и наоборот.

Полное восстановление пользователя

Исключение файлов и баз из резервного копирования

Задать список исключаемых файлов можно в настройках модуля резервного копирования. Пути задаются относительно домашнего каталога пользователя, например data/.filemgr-tmp. В фильтрах файлов можно использовать регулярные выражения(*). Указанные файлы не будут участвовать в процессе резервного копирования. В поле ниже можно исключить базы. Их нужно указывать в формате полное имя базы в отдельной строке.

Как изменить время запуска резервного копирования

По умолчанию резервное копирование делается ежедневно. Для ISPmanager Business системные задания в интерфейсе панели не отображаются, поэтому задание нужно менять вручную, подключившись к серверу через SSH или локальную консоль. Задание в кроне выглядит следующим образом:

0 3 *	/usr/local/mgr5/sbin/cron-ispmgr sbin/backup2_pro >/dev/null 2>&1

Как ограничить время резервного копирования

Задать временной диапазон, когда должно выполняться резервное копирование, можно через параметр (BackupTimeInterval). Например: BackupTimeInterval 03:00:00-06:00:00 указывает, что резервное копирование должно проводиться с 3х до 6 часов ночи. Резервное копирование отдельного пользователя прерываться не будет. Если система не успеет скопировать всех пользователей в указанный промежуток времени, резервное копирование оставшихся пользователей будет продолжено на следующий день. При этом новых копий за этот день создаваться не будет.

Например: в понедельник 14.09.2015 мы успели скопировать 10 пользователей из 15. Значит, во вторник будут скопированы оставшиеся 5, а следующая резервная копия для всех пользователей будет сделана уже в только в среду 16.09.2015. Резервные копии всех пользователей будут иметь дату 14.09.2015, несмотря на то, что часть пользователей будет скопирована только 15.09.2015

Как освободить место в хранилище

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

Как ускорить процесс резервного копирования

При необходимости скопировать большой объем данных, вы можете изменить приоритет резервного копирования в конфигурационном файле etc/ispmgr.conf, за который отвечает параметр BackupCommandPrefix. По умолчанию значение параметра nice -n 10 ionice -c2 -n7.

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

ionice используется для получения и установки класса и приоритета процесса. Подробности смотрите здесь

Служебные файлы резервной копии

Файл с расширением tgz хранит данные о файлах резервной копии.

Файл с расширением info хранит информацию о дате создания, имени последнего файла копии, размере и типе бэкапа.

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

Ограничение кол-ва резервных копий

Общее кол-во хранимых резервных копий для каждого из пользователей регулируется параметром BackupCountLimit в etc/ispmgr.conf.

Нечетное количество хранимых резервных копий

Если параметр BackupCountLimit имеет нечетное значение, например 15, то будет 8 полных и 7 ежедневных дифференциальных резервных копий. При превышении лимита будет удаляться в первую очередь ежедневная дифференциальная резервная копия. То есть, количество полных резервных копий и дифференциальных все равно будет стремиться к равному соотношению, но полных копий будет на одну больше.

Как часто можно сделать новую резервную копию

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

Резервная копия пользователя

Для пользователя доступно создание одной резервной копии независимо от расписания, установленного через планировщик. Создать такую копию можно кнопкой «Новый» в списке резервных копий под пользователем панели. Такая же копия появляется в списке копий при импорте пользователя из архива *.tar.gz, который создается при скачивании резервной копии из панели. Повторное создание пользовательской резервной копии или импорт пользователя из архива *.tar.gz заменит существующую пользовательскую копию.

Резервная копия удаленного пользователя

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

Соотношение полных и ежедневных резервных копий

При первом запуске резервного копирования создается полная резервная копия. В последующие дни, если день недели не воскресение, создаются ежедневные дифференциальные резервные копии. В воскресение в любом случае создается полная резервная копия. В первые 14 дней получится соотношение 3 полных и 11 дифференциальных. По прошествии 14 дней начнут удаляться в первую очередь самые старые дифференциальные резервные копии. После того как у полной резервной копии не останется дифференциальных частей, она будет удалена. Следовательно, соотношение 7 полных и 7 дифференциальных резервных копий будет достигнуто приблизительно через 2 месяца.

Удаление резервных копий

Автоматическое

Автоматическое удаление наиболее старых незаблокированных резервных копий происходит

• при достижении лимита на размер хранилища,
• при достижении 95% заполнения раздела диска (для локального хранилища),
• при достижении кол-ва копий отдельного пользователя (BackupCountLimit), удаляется именно старый бэкап пользователя, превысившего лимит.

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

Ручное

Под администратором в списке резервных копий доступна кнопка «Удалить».

Для того, чтобы удалить резервную копию вручную, необходимо перейти в директорию /usr/local/mgr5, задать корректно переменную окружения BACKUP_TOKEN и выполнить команду sbin/backup2_cp —delete указав путь к info файлу резервной копии. Значение токена хранится в etc/ispmgr.conf в параметре BackupToken.

BACKUP_TOKEN="type=local;url=/var/backups/";sbin/backup2_cp --delete var/backup/ispmgr/2015-09-08.username.info

BACKUP_TOKEN="password=qwerty12345;type=ftp;url=[ftp://backup5.reserv.net;username=ftpuser23|ftp://backup5.reserv.net;username=ftpuser23] "; ls -1 var/backup/ispmgr/*username.info | xargs -I {} sbin/backup2_cp --delete {}

Пример удаления всех резервных копий в локальном хранилище:

BACKUP_TOKEN="type=local;url=/var/backups/"; ls -1 var/backup/ispmgr/*.info | xargs -I {} sbin/backup2_cp --delete {}

Как изменить размер тома резервной копии

Изменить размер тома резервной копии через конфигурационный файл etc/ispmgr.conf.

Пример установки размера резервной копии 30 мегабайт

Восстановление/скачивание файла/базы данных/почтового ящика

Резервирование системных данных

Эти архивы не доступны из интерфейса панели, т.к. работать с ними нужно крайне редко.

Чтобы восстановить данные, нужно перейти в хранилище (например /var/backup). Выбрать файл архива корневого пользователя (обычно, root) за нужную дату и посмотреть содержимое архива командами:

/usr/local/mgr5/sbin/isptar -l F2015-09-16.root.tgz
tar -tf F2015-09-16.root.tgz

После, выбранный файл извлечь:

Пример извлечения файла ispmgr.root.dashboard.xml:

tar -zxvf F2015-09-16.root.tgz usr/local/mgr5/var/userconf/ispmgr.root.dashboard.xml

Сколько нужно места для работы резервного копирования

На сервере

Временная директория панели: по умолчанию /usr/local/mgr5/tmp Системная директория панели: по умолчанию /usr/local/mgr5/var/backup/ispmgr Размер одной части архива: по умолчанию 100Мб, меняется через опцию BackupSliceSize

При работе с нелокальным хранилищем:

В пользовательской дисковой квоте

Пользователю нужно иметь места как минимум на 1 часть бэкапа (по умолчанию 100Мб), это нужно потому, что архивация выполняется с правами пользователя и часть архива до заливки на хранилище принадлежит пользователю. Сделано так из соображений безопасности.

Как изменить временную директорию

Если вам крайне необходимо изменить временную директорию, остановите все процессы панели, скопируйте директорию /usr/local/mgr5/var/backup/ispmgr и примонтируйте нужный раздел средствами операционной системы в /usr/local/mgr5/var/backup/ispmgr. Это обычно делается так:

mount --bind /нужный/раздел /usr/local/mgr5/var/backup/ispmgr

На данный момент резервное копирование после изменения пути до временной директории не всегда работает корректно. Не рекомендуется использовать описанный ниже параметр:

Если утилита killall отсутствует, то выполнить

/usr/local/mgr5/sbin/mgrctl -m ispmgr exit

Включение подробного журналирования

Чтобы увидеть все подробности работы новой системы резервного копирования в журналах панели нужно добавить следующие строки в etc/debug.conf:

backup2.* 9
backup2_import.* 9
backup2_download.* 9
backup2_cp.* 9
restore2.* 9
backup2_cgi.* 9
backup2_conv.* 9
backup2_system.* 9

и завершить работу панели командой killall core в SSH-консоли.

После чего можно включить вывод всех журналов резервного копирования так:

tail -f /usr/local/mgr5/var/backup2*log /usr/local/mgr5/var/restore2.log

Ручной запуск резервного копирования

За текущую дату

cd /usr/local/mgr5 && ./sbin/backup2_pro &

За определенную дату

Будьте осторожны с указанием даты далеко в будущем (больше чем BackupCountLimit/2 недель)! Если сделать копию в будущем и ещё одну с датой больше предыдущей, все копии за настоящее время могут быть удалены системой контроля размера резервных копий (даже если в копии за будущее не будет каких-то пользователей).

Не рекомендуется применять нижеописанный метод без крайней на то необходимости и готовности к последствиям!

cd /usr/local/mgr5 && ./sbin/backup2_pro --date 2016-05-01 &

За определенную дату определенного пользователя

Будьте осторожны с указанием даты далеко в будущем (больше чем BackupCountLimit/2 недель)! Если сделать копию в будущем и ещё одну с датой больше предыдущей, все копии за настоящее время могут быть удалены системой контроля размера резервных копий (даже если в копии за будущее не будет каких-то пользователей).

Не рекомендуется применять нижеописанный метод без крайней на то необходимости и готовности к последствиям!

cd /usr/local/mgr5 && ./sbin/backup2_pro --date 2016-05-01 user1 &

Ручная распаковка данных

Если у вас нет возможности восстановить данные через панель управления, но есть файлы из хранилища такого вида:

F2016-11-02.user.tgz.part1
F2016-11-02.user.tgz.part2

Вы можете склеить их обратно в архив так:

Команда для Unix (Linux/FreeBSD/MacOS):

cat F2016-11-02.user.tgz.part1 F2016-11-02.user.tgz.part2 > F2016-11-02.user.tgz

Команда для Windows:

copy /b F2016-11-02.user.tgz.part1 + /b F2016-11-02.user.tgz.part2 F2016-11-02.user.tgz

FAQ

Удаляются уже сделанные резервные копии

Возможна ситуация, при которой уже сделанные резервные копии внезапно удаляются из хранилища. При получении таймаута в 15 минут при FTP хранилище система резервного копирования считает, что кончилось место и удаляет наименее значимый бэкап из старых.

Файлы пользователей не включаются в резервную копию

GoogleDrive. Удаление директории в которую подключено резервное копирование в корзину

При необходимости удалить директорию в хранилище GoogleDrive, сначала необходимо отключить резервное копирование в ISPmanager, иначе поведение резервного копирование будет непредсказуемым.

Бэкапы на хостинге и виртуальном сервере: настраиваемые и автоматические

Полные резервные копии на виртуальном хостинге создаются автоматически: по средам и субботам. 2 резервные копии хранятся не менее 2 недель. Вы не можете изменить время автоматической генерации бэкапов, но можете вручную создать дополнительную резервную копию через панель ISPmanager.

1. Найдите раздел Резервные копии в левом списке.
2. Можно скачать готовые копии.
3. Кнопка Новый позволяет создать свою резервную копию. Её также можно скачать, но удалить только по запросу в поддержку.
4. В воскресенье можно создать полный бэкап, в списке он будет обозначен синим. В другие дни — дифференциальный (для файлов, которые были изменены), он чёрный в списке.

На виртуальном и выделенном сервере резервное копирование настраивается вручную. Включите бэкапы в ISPmanager — панель будет делать полные копии раз в неделю и дифференциальные раз в сутки.

Администратор (root) может настроить и восстановить резервные копии всех пользователей на сервере, отдельный пользователь — только свои.

Как включить резервное копирование данных?

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

1. Чтобы включить бэкап, зайдите в панель управления ISPmanager, перейдите в раздел Резервные копии. Если делаете это впервые, сразу попадёт в настройки.
2. Отметьте галочкой Включить резервное копирование и выберите Тип хранилища. Локальный каталог означает, что копии будут храниться на вашем сервере и занимать место его дискового пространства.
3. Укажите путь к каталогу на сервере, в который будут помещаться копии.
4. Установите общий объем хранилища бэкапов.
5. Укажите количество полных копий и дифференциальных (дневных). Это влияет только на хранение, как и общий размер копий.
   Например, если поставить 3 дифференциальных копии, их всегда будет только 3, даже если места достаточно для 4. Если они делаются ежедневно, лишние будут удаляться и вместо 6 (созданных за неделю) будет храниться только 3.

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

Так как на Windows-сервере нет панели ISPmanager, резервное копирование там можно настроить с помощью Acronis.

Как восстановить данные из резервной копии?

Зайдите в панель управления ISPmanager в раздел Резервные копии. Выберите копию, из которой хотите восстановить данные (полные обозначены синим, дифференциальные — чёрным). Нажмите Смотреть файлы на панели инструментов.

Выберите пользователя, чьи данные нужно восстановить, и нажмите кнопку Восстановить.

Для чего нужен внешний диск для бэкапов?

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

Заказывайте диски размером до 2000 Гб (дополнительная услуга «Диск для бэкапов») за 7 руб./Гб в месяц. Это поможет защитить ваш бизнес от потери важной информации и восстановить работоспособность сервера за несколько часов.

Как включить бэкап на внешний диск?

После оплаты услуги перейдите в панель управления ISPmanager в раздел Резервные копии и нажмите Настройки резервного копирования на панели инструментов.

Установите флажок Включить резервное копирование, выберите тип хранилища FTP, заполните поля «Адрес сервера», «Пользователь» и «Пароль» данными, полученными при покупке диска для бэкапов.

Найдите секцию Доступ по протоколу FTP, в строке Адрес указан адрес сервера, пользователь и пароль соответственно.

Как рассчитать, сколько места нужно для бэкапов?

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

Так как 1 Мебибайт = 1.04 Мегабайта, т.е. 10 Гибибайтов почти 11 Гигабайтов. Это важно учесть для корректной работы модуля. И, указывая максимальный размер всех копий, немного его преуменьшить. Например, если всего места 50 Гигабайт, то указывать нужно 45 Гибибайт.

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

1. Нужное количество полных копий + средний объем дневных * 1.5.
2. Нужное количество полных копий + ещё два полных для дневных.

Это примерные формулы, проверьте, подходят ли они в вашем случае.

Как изменить время создания резервных копий?

Полные резервные копии VDS создаются раз в неделю — только по воскресеньям, изменить время их генерации нельзя.

Дифференциальные копии создаются раз в сутки — с понедельника по субботу, доступна тонкая настройка времени через Cron.

1. В левом меню перейдите в раздел Планировщик CRON.
2. В cron-заданиях найдите строчку с описанием ISPmanager backup task.
3. Откройте задание в базовом режиме и увидите интуитивно понятные настройки времени. Формат исчисления 24-часовой.

Рассмотрим, как настроить резервное копирование в панели управления ISPmanager.

Зайдите в панель управления сервером под администратором (root) и перейдите в раздел Резервные копии, согласитесь настроить резервное копирование и поставьте галочку в поле Включить резервное копирование.

Если в ISPmanager существует только один пользователь, root, то резервное копирование будет выполняться только для настроек этого пользователя. Данные сервера не будут резервироваться. Владельцам виртуального хостинга нет причин беспокоиться – мы делаем резервные копии всех данных автоматически.

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

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

Так как на Windows-сервере нет панели ISPmanager, резервное копирование там можно настроить с помощью Acronis.

Для виртуальных и выделенных серверов мы предлагаем услуги автоматического резервного копирования (автобэкапы). Услуга «Резервное копирование» позволяет работать с бэкапами как на серверах с панелью управления ISPmanager, так и без неё — на сервере c операционными системами Ubuntu, Centos и Debian и их версиями. 

Инструкция по восстановлению требует навыков работы с командной строкой. Если у вас нет возможности восстановить копию своими силами, напишите нам в Личном кабинете — раздел «Поддержка», «Запросы». Мы поможем развернуть нужный бэкап.

Если с ISPmanager процесс восстановления резервных копий выполняется в самой панели и достаточно прост, то без панели восстанавливать копии необходимо вручную, подключившись к серверу по SSH или VNC.

Типы резервных копий

В рамках услуги «Резервное копирование» создаются полные (еженедельные) копии и дифференциальные (ежедневные) копии. Они отличаются по смыслу и содержанию.

Архив с полной копией содержит все файлы, которые содержались в копируемых директориях на момент создания бэкапа. Первый раз он создаётся после подключения услуги по расписанию, далее — каждую неделю по воскресеньям. Чтобы его было легко отличить от дифференциальной копии, в начало имени архива добавлена буква «F» (full).

Архив с дифференциальной копией содержит копии файлов, которые изменились с момента создания последнего полного бэкапа. Он создаётся ежедневно с понедельника по субботу. Для отличия от архива с полной резервной копией в начале имени дифференциального архива добавлена буква «I» (incremental).

Дифференциальные копии привязаны к полным. Чтобы восстановить данные за определённую дату, сначала нужно развернуть последнюю полную копию (за последнее воскресенье до нужной даты). После этого — поверх с заменой распаковать дифференциальный архив.

Чтобы при создании резервных копий не расходовалось место на диске, копии на сервере создаются фрагментами по 100 Мб — «слайсами». После создания фрагмента копии он загружается на внешнее хранилище и удаляется с локального диска вашего сервера, чтобы не занимать дисковое пространство. Далее начинается создание следующего слайса, и так по кругу, пока копия не будет полностью сохранена на удалённом хранилище. Это позволяет минимизировать потребление ресурсов сервера — места на диске, сетевого трафика.