От первой копии
до восстановления

01 / Первый запуск · 6 минут

Установка агента на Windows и Linux

До установки определите, что именно нужно защищать: каталог документов, подготовленные копии СУБД или экспорт виртуальной машины. Не включайте весь диск без разбора: временные файлы, кэши и повторяющиеся архивы увеличивают очередь.

1. Получите установочный пакет. Кабинет. В разделе загрузок кабинета или запросом в поддержку возьмите версию для вашей ОС и архитектуры, контрольную сумму и требования к системе. Не используйте пакеты из неофициальных источников. Адрес хранилища и сведения для подключения выдаются при подключении услуги.
2. Подготовьте права. Сервер. На Windows установка службы требует прав администратора; самой службе нужен доступ к выбранным каталогам. Там же проверьте, что служба теневого копирования тома (VSS) включена и на томе есть место под снимки: без неё открытые файлы будут скопированы негодными. На Linux назначьте отдельного системного пользователя и права чтения источников; аналога VSS здесь нет, поэтому для постоянно открытых файлов используйте снимок файловой системы. Для сетевой папки проверьте доступ именно от имени службы.
3. Установите и привяжите агент. Сервер. На Windows используйте подписанный установщик; на Linux — пакет для вашего дистрибутива и инструкцию, которая идёт с ним. Укажите организацию, выданные параметры подключения и ключ шифрования. Сохраните резервную копию ключа отдельно. После привязки узел появится в списке личного кабинета.
4. Выберите данные и исключения. Агент. Отметьте каталоги и подготовленные копии в самом агенте на сервере. Для открытых баз используйте согласованную копию средствами СУБД. Проверьте свободное место под временные данные и исходящее HTTPS-соединение к выданному адресу.
5. Выполните первую копию. Агент. Запустите задание и дождитесь завершения: первая копия идёт по объёму, при 100 Мбит/с это около 45 ГБ в час. Проверьте время сохранённой точки и отсутствие ошибок — оно видно и в агенте, и в кабинете. Затем восстановите один тестовый файл в отдельный каталог и сравните его с исходным.

02 / Политика резервирования · 5 минут

Как настроить расписание и срок хранения

Начните с двух величин: сколько изменений бизнес может потерять и сколько времени может ждать восстановления. Например, интервал 5 минут — целевой шаг сохранения, но медленный канал способен увеличить фактическую задержку.

1. Разделите источники. Агент. Документы, крупные архивы и базы данных лучше резервировать отдельными заданиями. Для каждого задайте своё расписание и исключения.
2. Выберите интервал. Агент, задание. Для рабочих папок включите непрерывное отслеживание и передачу изменений каждые несколько минут. Для полной копии базы назначьте период низкой нагрузки. Копирование результата запускайте только после успешного завершения резервирования СУБД.
3. Задайте время и полосу. Агент, настройки. Проверьте часовой пояс сервера и синхронизацию часов. Ограничьте исходящую скорость так, чтобы первая копия не мешала рабочим приложениям.
4. Настройте историю. Агент, хранение. Базовый пример — 30 дней версий, включая удалённые файлы. Точки прореживаются: подробная пятиминутная сетка хранится сутки, затем остаётся по одной точке в час за неделю и по одной в сутки до конца срока. Так месяц истории — это порядка сотни точек на файл, а не тысячи. Учитывайте скорость изменения данных и доступный объём: срок хранения не отменяет лимит места.
5. Проверьте результат через сутки. Кабинет. Сопоставьте время последней точки с расписанием, изучите ошибки и рост хранилища. Там же включите уведомления: суточный отчёт о заданиях на почту, письмо при ошибке и предупреждение о тишине, если по источнику нет успешной точки дольше заданного времени. Если очередь не сокращается, увеличьте пропускную способность или измените состав задания.

Периодически повторяйте пробное восстановление. Для критичных источников оформите отдельный порядок проверки и назначьте ответственного.

03 / Возврат данных · 4 минуты

Восстановление удалённого или изменённого файла

Сначала определите последнюю подходящую версию: когда файл ещё содержал нужные данные. История доступна только в пределах установленного срока хранения.

1. Выберите источник и точку. Агент. На том сервере, куда возвращаете данные, откройте набор резервирования, найдите нужный файл и сохранённую версию до удаления или ошибочного изменения. Перечень наборов и доступных точек виден и в личном кабинете. Учитывайте часовой пояс отображаемого времени.
2. Укажите отдельный каталог. Агент, мастер восстановления. Например, C:\Restore на Windows или /srv/restore на Linux. Это позволит проверить файл до замены рабочего экземпляра. Убедитесь, что места достаточно и каталог закрыт от посторонних.
3. Предоставьте ключ шифрования. Агент. Используйте ключ, которым зашифрован выбранный набор. Не вводите его в кабинете и не отправляйте в переписке с поддержкой.
4. Проверьте результат. Целевой сервер. Откройте документ в штатном приложении, проверьте размер, содержимое и при наличии эталона — контрольную сумму. Права доступа и владельца при необходимости восстановите по своему регламенту.
5. Верните файл в работу. Рабочая папка. Сохраните текущий экземпляр отдельно, согласуйте замену с пользователем и только затем перенесите проверенную версию в рабочую папку.

04 / Смена инфраструктуры · 7 минут

Перенос резервирования на новый сервер

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

1. Подготовьте целевую систему. Проверьте совместимость ОС, приложений и СУБД, свободное место, пути хранения и права служебной учётной записи.
2. Установите агент на новом сервере. Используйте действующий пакет и отдельные параметры идентификации узла. Не копируйте служебный идентификатор работающего старого агента: два узла не должны представляться одним источником.
3. Восстановите в промежуточный каталог. Агент на новом сервере. Проверьте документы и базу на тестовом экземпляре. Ключ шифрования передайте по утверждённому защищённому каналу.
4. Согласуйте переключение. Остановите запись в старую систему, создайте финальную согласованную копию и дождитесь её передачи. Восстановите оставшиеся изменения на новом сервере и проверьте приложение.
5. Подключите новое задание. Агент, затем кабинет. Проверьте пути, исключения, расписание, часовой пояс и успешную первую точку нового узла. После этого отключите старое задание и отзовите ненужные учётные данные в кабинете.

Старую историю сохраняйте до завершения согласованного периода отката. Для систем, которым недопустима остановка, отдельно спланируйте миграцию штатными средствами СУБД.

05 / Согласованность данных · 8 минут

Как резервировать 1С, PostgreSQL и MySQL

Копирование файлов работающей базы без согласования с СУБД может дать непригодную копию. Агент передачи данных не заменяет механизм резервирования базы.

1С:Предприятие

Для файловой базы завершите работу пользователей и фоновых заданий, затем копируйте каталог информационной базы целиком: кроме 1Cv8.1CD в нём лежат журнал регистрации 1Cv8.lgd и старый формат 1Cv8.1CL, а также служебные файлы. Один 1Cv8.1CD без остального восстанавливает базу, но теряет журнал регистрации. Убедитесь, что во время копирования никто не открывает базу. В клиент-серверном режиме используйте штатное резервирование соответствующей СУБД. Выгрузка .dt требует монопольного режима и не является универсальной заменой регулярного резервного копирования. Проверяйте копию восстановлением в отдельную информационную базу.

PostgreSQL

Для логического переноса можно использовать pg_dump и pg_restore, а роли, табличные пространства и прочие глобальные объекты выгружать отдельно командой pg_dumpall --globals-only — в дамп отдельной базы они не попадают. Для восстановления на выбранный момент нужна физическая базовая копия, например через pg_basebackup, и непрерывный архив WAL начиная с этой копии: его включают параметрами archive_mode и archive_command, а нужный момент задают в recovery_target_time. Утрата части WAL обрывает доступный диапазон восстановления. Логическая выгрузка сама по себе такой возможности не даёт.

MySQL

Сначала создайте согласованную полную копию, зафиксировав соответствующую позицию binlog или GTID: mysqldump --single-transaction --source-data=2 снимает её без остановки записи, но согласованность при этом получают только таблицы InnoDB — MyISAM и MEMORY придётся блокировать отдельно. Затем сохраняйте двоичные журналы и проверяйте, что их цепочка не прерывается. Для восстановления верните полную копию и примените нужную часть журналов штатными средствами, включая mysqlbinlog. Конкретный способ зависит от версии MySQL и используемых движков таблиц.

06 / Доступ к копиям · 4 минуты

Как хранить ключ шифрования

Пароль учётной записи и ключ шифрования решают разные задачи. Пароль открывает доступ к сервису; ключ позволяет расшифровать содержимое резервных копий.

1. Назначьте ответственных. Определите, кто может получить ключ и кто имеет право одобрить восстановление. Предусмотрите отсутствие основного администратора.
2. Сохраните ключ отдельно. Используйте корпоративный менеджер секретов и защищённую резервную копию по вашему регламенту. Единственная копия на резервируемом диске может исчезнуть вместе с сервером.
3. Проверьте доступ на практике. Восстановите небольшой набор с другого подготовленного устройства. Убедитесь, что ключ подходит, не раскрывая его в журнале проверки.
4. Учитывайте старые версии. При смене ключа сохраните необходимые прежние ключи до истечения срока хранения связанных копий. Смена пароля не перешифровывает историю автоматически.

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