Модуль резервного копирования (isptar, текущий актуальный модуль, c 5.52.0 )

Материал из ISPWiki
Перейти к: навигация, поиск

В ISPmanager (Lite и Business), начиная с версии 5.52.0, реализована новая система резервного копирования, построенная на основе ISPtar (Техническая документация к ISPtar).

В ISPmanager Lite эта система заменит систему с использованием DAR.

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

Содержание

Что нового

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

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

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

BackupCountLimit 7:7

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

До версии 5.137 в конфигурационный файл ispmgr.conf параметр правильно прописывается так:

BackupCountLimit 8

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

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

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

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

Переход от старой системы резервного копирования к новой

При обновлении панели ISPmanager Lite до новой версии система резервного копирования DAR заменяется на ISPtar: подключается то же хранилище, из интерфейса панели перестают быть доступны старые резервные копии (сами файлы не удаляются из хранилища), их можно сконвертировать в новый формат, запустив вручную /usr/local/mgr5/sbin/backup2_conv (процесс может занять длительное время, потребует дисковой квоты пользователя для хранения файлов после распаковки из DAR и до запаковки в ISPtar).

Если после подключения хранилища с DAR и запуска конвертера не появилось ни архивов в интерфейсе, ни ошибок в журнале var/backup2.conv, следует скопировать вручную информационные файлы из хранилища во временную директорию панели и запустить конвертер заново:

Обратите внимание, если вы перенесли резервные копии на новый сервер, убедитесь, что на нём установлен dar

cd /usr/local/mgr5
cp -pr /<хранилищеDARов>/201*dar var/backup/ispmgr/
cp -pr /<хранилищеDARов>/*info var/backup/ispmgr/
sbin/backup2_conv &

С ещё более ранней системой резервного копирования (которая включается опцией EnableOldBackup) ISPtar не конфликтует и обе системы могут использоваться параллельно.

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

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

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

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

Это поле позволяет задать максимальный размер, занимаемый резервными копиями на хранилище (в случае локального хранилища на ISPmanager Business это ограничение применяется к каждому узлу по отдельности). При первом подключении локального хранилища начиная с версии панели 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 ' '

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

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

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

Пользовательское хранилище

С версии 5.58 у пользователей ISPmanager Business есть возможность настроить собственное удалённое хранилище (указание хранилищем того же пользователя через FTP/SFTP не рекомендуется, т.к. может вызвать проблемы). Можно настроить лимит по размеру, но исключения баз/файлов будут применены администраторские (т.к. по сути делается одна копия в администраторское хранилище, а потом копируется в пользовательское).

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

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

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

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

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

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

Начиная с версии 5.57.0 (выпущена 17.05.2016) можно в ISPmanager Lite импортировать архивы из cPanel.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Внимание! В версии 5.136.0 изменена структура хранилища. Файлы резервных копий теперь распределяются в поддиректории, в зависимости от имени пользователя и даты. В случае, если перед обновлением панели до версии 5.136 была создана пользовательская копия, то при повторном создании пользовательской копии или импорте пользователя из архива *.tar.gz, предыдущая копия не будет удалена.

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

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

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

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

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

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

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

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

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

Ручное

Под администратором (и под пользователем в собственном хранилище в ISPmanager Business) в списке резервных копий доступна кнопка "Удалить".

Для того, чтобы удалить резервную копию вручную, необходимо перейти в директорию /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"; 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

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

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

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

Архивируются /usr/local/mgr5/etc, /usr/local/mgr5/var и /etc в архивы вида F2015-09-16.root.tgz на Lite и вида F2016-06-11.root#system_localhost.tgz и F2016-06-11.root#system_<remote_node_name>.tgz на Business.

С версии ISPmanager Business 5.59 в резервную копию system также входит mysql база сервера-мастера ispmgr. Дамп БД делается в кодировке по-умолчанию и кладётся в архив вида F2016-06-11.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

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

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

1) business:

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

2) lite:

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


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

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

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

1) business:

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

2) lite:

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

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

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

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

1) business:

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

2) lite:

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

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

FAQ

401 Unauthorized при Яндекс-хранилище

Если при скачивании копии в журнале видим такую ошибку:

libmgr ERROR Error: Type: 'file' Object: 'open_w' Value: '/usr/local/mgr5/tmp/allmerge_Net1uX'

А немного выше видим не 2XX/3XX HTTP-код ответов от ЯД, а такой:

HTTP/1.1 401 Unauthorized

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


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

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


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

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


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

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