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

резервного копирования и восстановления данных «Сибирь Софт»

Настоящий Регламент применяется совместно с Публичной офертой «Сибирь Софт», Специальными условиями предоставления виртуальных серверов и размещения сайтов, SLA и конкретным Заказом.

1. Основной принцип

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

1.2. Заказчик обязан самостоятельно иметь актуальную независимую копию критически важных данных.

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

1.4. Исполнитель создаёт внутренние технические копии VM и контейнеров средствами виртуализации. Конкретные даты имеющихся архивов не подтверждают договорную периодичность, неизменность состава, глубину хранения или успешность каждого восстановления. Эти параметры гарантируются только при прямом согласовании отдельной услуги.

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

2. Внутренние технические копии Исполнителя

2.1. Исполнитель вправе создавать резервные копии и снапшоты собственной инфраструктуры в целях:

• аварийного восстановления;
• технического обслуживания;
• миграции;
• обеспечения безопасности;
• защиты собственной инфраструктуры.

2.2. Такие копии являются внутренней технической мерой Исполнителя.

2.3. Если отдельная услуга копирования не согласована, внутренние технические копии не образуют персональный архив Заказчика с гарантированной периодичностью и сроком хранения. Они создаются в рамках технической политики и применимых требований безопасности:

• не предоставляются как гарантированная услуга;
• могут создаваться нерегулярно;
• могут содержать устаревшее состояние;
• могут быть повреждены;
• могут быть неполными;
• могут быть удалены в любой момент в рамках внутренней политики;
• могут временно не создаваться;
• могут быть полностью отключены Исполнителем.

2.4. Факт существования внутренней резервной копии в определённый момент не создаёт обязанности создавать такие же копии в будущем.

2.5. Изменение внутренней технической политики резервирования не считается изменением тарифа Заказчика, если гарантированное резервное копирование не было включено в Заказ.

2.6. Изменение внутренней технической политики не отменяет обязательные меры защиты данных, согласованное поручение, подтверждённые параметры отдельной услуги и применимые требования к срокам хранения и уничтожения.

3. Отдельная услуга резервного копирования

3.1. Гарантированное резервное копирование предоставляется только тогда, когда оно прямо указано в Заказе.

3.2. Для такой услуги стороны определяют:

Периодичность: ____________________

Количество копий: __________________

Срок хранения: ____________________

Место хранения: ___________________

Что резервируется: _________________

RPO: ______________________________

Целевое RTO: ______________________

Стоимость: ________________________ ₽

3.3. Параметры услуги должны быть заполнены и явно подтверждены до её запуска; пустые поля шаблона не являются заказом услуги и не создают обещания определённого RPO или RTO. Отсутствие параметра не отменяет прямо принятую обязанность и обязательные требования закона.

4. RPO

4.1. RPO — максимально допустимый временной интервал между последней резервной копией и моментом аварии.

4.2. Например, при резервном копировании один раз в сутки восстановленное состояние может не содержать изменения, внесённые после создания последней копии.

4.3. Если конкретное RPO не установлено в Заказе, гарантированный объём сохранения последних изменений отсутствует.

5. RTO

5.1. RTO — целевой срок восстановления услуги после подтверждения возможности восстановления из резервной копии.

5.2. RTO является гарантированным только при прямом указании соответствующего значения в Заказе.

5.3. Если RTO не установлен, восстановление выполняется в разумный технический срок без гарантии конкретного времени завершения.

6. Состав резервной копии

6.1. В зависимости от услуги резервная копия может включать:

• виртуальный диск VM;
• файлы сайта;
• базу данных;
• конфигурацию;
• отдельные каталоги;
• иной согласованный набор данных.

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

• внешних API;
• Telegram;
• MAX;
• стороннего облачного хранилища;
• домена;
• почты стороннего провайдера;
• данных на ресурсах третьих лиц;
• подключённых внешних дисков и систем.

7. Консистентность данных

7.1. Технический снимок VM может создаваться без остановки работающей системы.

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

7.3. Для критически важных баз данных рекомендуется использовать специализированное резервное копирование самой СУБД.

8. Хранение копий

8.1. Копии хранятся в течение периода, предусмотренного Заказом.

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

8.3. Удаление старой копии в рамках установленной ротации не является потерей данных по вине Исполнителя.

9. Запрос на восстановление

9.1. Заказчик вправе обратиться с просьбой восстановить данные из доступной резервной копии.

9.2. При обращении необходимо по возможности указать:

• VM или сайт;
• требуемую дату состояния;
• причину восстановления;
• какие данные необходимо восстановить.

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

9.4. Восстановление может привести к временной недоступности ресурса.

10. Восстановление из внутренних копий

10.1. Если Заказчик не приобретал услугу резервного копирования, но подходящая внутренняя копия существует, Исполнитель вправе попытаться произвести восстановление.

10.2. Такое восстановление осуществляется по принципу Best Effort.

10.3. Исполнитель не гарантирует:

• наличие подходящей копии;
• её целостность;
• требуемую дату;
• сохранение последних изменений;
• техническую возможность восстановления.

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

11. Действия Заказчика

Заказчик обязан:

• самостоятельно определять критичность своих данных;
• иметь независимые резервные копии важных данных;
• периодически проверять возможность восстановления собственных копий;
• не использовать единственную копию на инфраструктуре Исполнителя как единственное место хранения критически важной информации;
• сообщать об обнаруженной потере данных без необоснованной задержки.

12. Удаление VM и прекращение услуги

12.1. Перед удалением VM или прекращением услуги Заказчик обязан самостоятельно выгрузить необходимые данные.

12.2. После истечения установленного периода хранения Исполнитель вправе удалить основную VM и относящиеся к ней данные.

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

12.4. Наличие копии после прекращения услуги не создаёт обязанности хранить её до отдельного обращения бывшего Заказчика.

13. Компрометация VM

13.1. Резервная копия может содержать:

• вредоносное программное обеспечение;
• уязвимую конфигурацию;
• скомпрометированные данные;
• иные элементы, существовавшие на момент создания копии.

13.2. Восстановление такой копии не гарантирует устранение первоначальной причины инцидента.

13.3. Исполнитель вправе отказать в непосредственном восстановлении очевидно опасной копии в рабочую сеть до проведения необходимых мер безопасности.

14. Ответственность

14.1. Если услуга гарантированного резервного копирования не заказана, отсутствие внутренней технической резервной копии само по себе не является нарушением договора Исполнителем.

14.2. Исполнитель не отвечает за невозможность восстановления из резервной копии, если соответствующее гарантированное резервное копирование не являлось предметом договора, кроме случаев ответственности, которую нельзя исключить или ограничить законом.

14.3. При приобретённой услуге резервного копирования ответственность определяется согласованными параметрами Заказа, Публичной офертой и законодательством Российской Федерации.

14.4. Настоящий Регламент не ограничивает обязательные права Потребителя.

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

15. Приоритет документов

Приоритет имеют обязательные нормы закона. Затем применяются подписанный или явно подтверждённый Заказ и его приложения в согласованной версии. По специальным вопросам применяются: поручение — к обработке данных клиента, согласованные параметры резервного копирования — к копиям, SLA — к доступности, условия размещения — к инфраструктуре. Общие положения Оферты дополняют эти документы. Техническое описание не может односторонне расширять обязанности или снижать гарантии, прямо согласованные сторонами.

16. Реквизиты

Фролов Руслан Сергеевич

ИНН: 222331724711

Налогоплательщик налога на профессиональный доход

«Сибирь Софт»

E-mail: sibirsoft-it@mail.ru

Телефон: +7 (962) 816-68-81

Редакция применяется к новым Заказам. Изменение уже согласованного договора — по соглашению сторон и обязательным правилам закона; публикация новой редакции не меняет его задним числом.