Документация ispmanager 6 business

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

 

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

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

Что нового

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

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

Минимальное рекомендуемое значение параметра 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 ' '

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

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

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

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

Чтобы посмотреть содержимое старого файла, скачайте файл из резервной копии.

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

Чтобы восстановить данные пользователя из резервной копии, перейдите в ИнструментыРезервные копии → выберите копию → кнопка Подробнее → выберите пользователя → кнопка ВосстановитьOK. Когда данные будут восстановлены, в интерфейсе ispmanager появится сообщение "Восстановление из резервной копии успешно завершено".

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

Задать список исключаемых файлов можно в настройках модуля резервного копирования. Пути задаются относительно домашнего каталога пользователя, например 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 используется для получения и установки класса и приоритета процесса. Подробности смотрите здесь

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

После создания резервной копии, в директории /usr/local/mgr5/var/backup/ispmgr создаются файлы вида 2015-08-12.user.tgz и 2015-08-12.user.info. Эти файлы не содержат саму резервную копию, а предназначены для хранения служебной информации.

Файл с расширением 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.

Пример удаления одной резервной копии из локального хранилища для конкретного пользователя (username):

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

Пример удаления всех резервных копии из удалённого хранилища с типом ftp для конкретного пользователя (username):

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 мегабайт

BackupSliceSize 30M

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

От администратора это не возможно, нужно зайти под пользователем (можно прямо из интерфейса Резервные копии нажать кнопку "Войти") внутрь резервной копии, выбрать файл(-ы)/базу(-ы) и нажать на "Восстановить"/"Скачать". 

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

Архивируются /usr/local/mgr5/etc, /usr/local/mgr5/var/userconf и /etc в архивы вида F2015-09-16.root.tgz

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

Чтобы восстановить данные, нужно перейти в хранилище (например /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 часа (закэшированный архив).Места в системной директории нужно столько, сколько весят архивы всех пользователей (если все в течение часа захотят сделать новый архив). Места во временной директории нужно в два раза больше чем размер части архива.
Импорт архива пользователемПри импорте архива пользователем, происходит его загрузка в системную директорию, распаковка (при необходимости конвертация), запаковка и отправка по частям на хранилище.Места в системной директории нужно столько, сколько весят архивы всех пользователей (если все в течение часа захотят сделать новый архив).
Скачивание архиваПри скачивании архива все части скачиваются с хранилища во временную директорию, там же объединяются в один архив. Этот архив перемещается отдаётся пользователю в браузер и в течение часа ещё хранится в системной директорий (закэшированный архив).Места в системной директории нужно столько, сколько весят архивы всех пользователей (если все в течение часа захотят сделать новый архив). Места во временной директории нужно в два раза больше чем размер части архива.

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

Пользователю нужно иметь места как минимум на 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

Полученный архив F2016-11-02.user.tgz уже можно будет открыть стандартными средствами вашей ОС, но его импорт в ispmanager невозможен.

FAQ

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

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

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

В случае, если каталоги пользователей подключены как отдельные разделы, их файлы из домашней директории(например, /var/www/user/data/www/*) не будут включены в резервную копию.

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

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

 

В этой статье