Я использую Duplicity почти на каждом хосте, который я обслуживаю, для создания резервных копий в удаленном месте (называя его «хостом резервного копирования»).
Частота и время выполнения полного или инкрементного резервного копирования зависит от хоста и его варианта использования.
Я пытаюсь не только защитить себя от типичных сбоев (человеческий фактор, аппаратное или программное обеспечение и т. д.), но и восстановиться после потенциальной атаки.
В моих случаях я использую бэкэнд SSH/SFTP для запуска таких резервных копий duplicity. Поскольку duplicity нужен доступ на чтение/запись к хосту резервного копирования, кто-то, получивший контроль над хостами, которые должны быть скопированы, может также подключиться к хосту резервного копирования и удалить/испортить соответствующие резервные копии.
Несмотря на это, насколько я понимаю, хостам, подлежащим резервному копированию, также /нужно/ удалить файлы на хосте резервного копирования: Чтобы не исчерпать свободное место, мои хосты, подлежащие резервному копированию, часто вызывают дублирование с помощью remove-all-but-n-full- и remove-all-inc-of-but-n-full-действий, чтобы удалить старые резервные копии.
Насколько мне известно, такие очистки не могут выполняться на самом резервном хосте, поскольку резервные копии (включая метаданные Duplicity относительно того, какие файлы относятся к какому набору) зашифрованы, а соответствующий закрытый ключ (GPG) на резервном хосте отсутствует.
Таким образом, чтобы выполнить такую очистку на резервном хосте, мне придется делать это на основе временных меток файлов, что может привести к повреждению/частичности наборов резервных копий.
В настоящее время, чтобы «защитить» себя от такой атаки, у меня есть второй резервный хост, регулярно подключающийся к основному резервному хосту, который через rsync передает все резервные данные с основного на дополнительный резервный хост.
Но здесь я снова сталкиваюсь с уже упомянутыми выше проблемами:
- Я просто копирую файлы с основного на второй резервный хост, не имея ни малейшего представления об их структуре (например, я копирую еще не завершенные файлы, частичные наборы и т. д.).
- Чтобы не исчерпать свободное место, мне придется снова удалять устаревшие резервные копии исключительно на основе временных меток файлов, что может сделать наборы резервных копий непригодными для использования.
Какой самый элегантный и чистый способ автоматического резервного копирования хостов, подлежащих резервному копированию, с помощью дублирования, при этом гарантируя, что злоумышленник, получивший полный доступ к хостам, подлежащим резервному копированию, не сможет испортить уже созданные резервные копии?
Большое спасибо!