5

Эффективен ли rsync для передачи зашифрованных файлов? Более конкретно:

  • Я зашифровываю 'x' своим открытым ключом и вызываю результат 'y'.
  • Я rsync 'y' на мой резервный сервер.
  • «х» меняется незначительно
  • Я зашифровал измененный 'x' и rsync измененного 'y' на свой резервный сервер.

Это эффективно? Я знаю, что небольшое изменение в 'x' приводит к большому изменению в 'y', но локализовано ли изменение? Или «y» изменилось настолько тщательно, что rsync не намного лучше, чем scp?

В настоящее время я выполняю резервное копирование своих "критических" файлов, копируя их по ночам, затем шифруя файл .tar.bz и отправляя его на свой резервный сервер.

Многие из отдельных файлов не изменяются, но, конечно, файл tar изменяется, если даже один из файлов изменяется.

Это эффективно? Должен ли я шифровать и создавать резервные копии каждого файла в отдельности? Таким образом, неизмененные файлы не потребуют времени для rsync.

Изменить, чтобы добавить больше информации:

  • Источник моей домашней машины. Я владею им и считаю это безопасным.

  • Целевой объект - это совместный сервер. Это мое, но компания-колокейшн могла видеть любой / весь сетевой трафик и все что угодно на жестком диске этой машины.

  • У источника очень мало свободного места. Я не хочу вдвое сократить пространство, храня зашифрованную резервную копию на нем.

  • У цели много места.

Есть мысли, основанные на этой новой информации?

|источник

3 ответа3

4

Прежде всего, поздравляю с серьезным отношением к резервным копиям.

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

Вам было бы еще лучше (опять же, смотря только на время передачи), пропустив tar-архивы и просто повторно выполняя иерархию зашифрованных / сжатых файлов.

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

OTOH, с точки зрения безопасности, шифрование архива скрывает имена файлов и шаблоны изменений, предотвращая анализ трафика.

Я не вижу способа использовать просто rsync для получения как инкрементных резервных копий, так и полной безопасности.

Обновить:

Если вы контролируете оба конца, вы можете использовать rsync -e ssh -a ... ; это будет использовать ssh-туннель (который также обеспечит сжатие при правильной настройке ssh_config), и тогда вы действительно сможете получить лучшее из обоих миров.

И для окончательной мысли, проверьте rdiff-backup.

|источник
2

Смотрите этот ответ. Резервное копирование жесткого диска 80 ГБ 1 ГБ в день в отношении rsyncrypto, как обсуждалось на Linux.com

Также внешнее резервное копирование с использованием rsync и aes

|источник
1

Если вы используете GNU tar (и, возможно, другие), вы можете создать tar-файл из всех ваших файлов для резервного копирования и сохранить его локально, а затем использовать «--append» для расширения файла любыми обновлениями. Поскольку все обновления файла заканчиваются, шифрование не скрывает неизмененные данные от rsync, поэтому оно работает очень эффективно. Недостатком является то, что в обоих местах требуется много места, которое увеличивается с каждой резервной копией. Плюс в том, что он делает последовательные резервные копии с историей изменений.

Если вы используете OS X, есть простое, более эффективное решение вашей проблемы: создайте зашифрованный образ диска с разреженным комплектом и выполните rsync.

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

Безопасность... Вы используете криптографию с открытым ключом, поэтому, если злоумышленник попадет в ваш ящик, для которого выполняется резервное копирование, у него не будет доступа к историческим данным? Я не могу придумать какую-либо другую причину использовать открытый ключ над AES. Помните, что rsync позволяет злоумышленнику уничтожить все резервные копии или перезаписать их чем-либо по своему выбору, когда у них есть доступ к ящику для резервного копирования.

|источник

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