Я нахожусь в процессе настройки того, что, я надеюсь, будет разумным, избыточным решением для резервного копирования для моего дома. У меня есть ноутбук с двойной загрузкой (Ubuntu и Windows) и домашний NAS. Идея состоит в том, чтобы настроить программное обеспечение резервного копирования в каждой ОС для резервного копирования на NAS, а затем выполнить резервное копирование NAS в облачное хранилище.

В основном это документы и фотографии, я думаю, общий объем составляет от 50 до 100 ГБ. Возможно, позже будут добавлены другие устройства, аналогичные тем, которые я делаю. Помимо размещения этих резервных копий, NAS также будет содержать большой репозиторий цифровых фотографий, который также должен быть включен в облачное резервное копирование.

Начнем со спины: мне вполне комфортно с идеей запустить скрипт резервного копирования с локального Raspberry Pi (у меня его уже несколько), используя двойственность для резервного копирования соответствующих каталогов NAS в хранилище Backblaze B2 с шифрованием GPG. сделано на стороне клиента - во многом по тому же принципу, что и детали этого блога:

https://msol.io/blog/tech/dirt-cheap-client-encrypted-online-backups-with-raspberry-pi/

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

Где я больше не уверен, как обрабатывать, это этап PC-to-NAS. Я начал с Ubuntu, встроенного в Deja Dup, но, понимая, что двуличность тоже используется в качестве бэкэнда, мне интересно:

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

Если это так, что может быть лучше? У меня была идея просто выполнять еженедельную (или любую другую) rsync от Ubuntu до NAS, поэтому у NAS просто есть копия 1:1, и шаг NAS-to-cloud может обработать всю хитрость восстановления с разных дат, шифрование и все остальное.

Недостатком этого может показаться эффективность на первом этапе, когда мне придется копировать много данных каждый раз, когда я делаю резервную копию. Возможно, с помощью опции rsync --link-dest будет работать жесткая привязка к любым существующим файлам, а не копирование их снова, но я не уверен, будет ли это надежным или даже работать с резервным копированием второго этапа с помощью дублирования.

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

1 ответ1

1

Anlag,

вы правы. ваши настройки избыточны. Duplicity упаковывает резервную копию Duplicity на ваш второй шаг.

то, что вы, вероятно, хотите

  1. легко доступные резервные копии на сайте (простые файлы, желательно снимки, чтобы вы могли восстановить только что удаленный файл со вчерашнего дня)
  2. зашифрованная резервная копия вне сайта, поэтому ваши данные защищены от шпионских глаз

, я бы предложил

  1. запуск простых резервных копий (например, rsync) на NAS (используйте btrfs для моментальных снимков, если у него достаточно мощности, иначе используйте rsync w/ --link-dest)
  2. использовать двуличность для резервного копирования их на удаленный

..ede/duply.net

Всё ещё ищете ответ? Посмотрите другие вопросы с метками .