Какие методы резервного копирования следует использовать в двухэтапном плане резервного копирования? (ПК на NAS в облаке)

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

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

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

1 ответ

Решение

Anlag,

вы правы. ваши настройки избыточны. duplicity is packaging a duplicity backup in your second step.

what you probably want is

  1. easily accessible backups on site (plain files, preferrably snapshotted so you can restore a just deleted file from yesterday)
  2. encrypted backup off site, so your data is protected from spying eyes

, i'd suggest

  1. running plain backups (eg rsync) to the NAS (use btrfs for snapshots if it has enough power, else use rsync w/ --link-dest)
  2. use duplicity to backup these to remote

..ede / duply.net

Другие вопросы по тегам