Как выбрать облачный сервис для резервного копирования

Я думаю об использовании облачного сервиса для резервного копирования одного из сайтов моего клиента.

Мои (клиенты) основные проблемы (в порядке убывания важности)

1. Защита IP (торговые секреты, исходный код), данные учетной записи пользователя и т. Д.
2. Гарантия работоспособности, предоставляемая поставщиком услуг (чтобы минимизировать время простоя веб-сервера)
3. Стоимость
4. Скорость загрузки / выгрузки

В идеале, я хотел бы, чтобы сервис не имел длительной связи (то есть я бы предпочел своего рода услугу с оплатой по мере использования)

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

Я хотел бы некоторые общие рекомендации по:

1. Как выбрать поставщика услуг
2. Кто основные игроки на поле?
3. рекомендации по использованию программного обеспечения для: резервного копирования / восстановления / и загрузки / скачивания сохраненных / восстановленных файлов

Серверное программное обеспечение будет либо Ubuntu, либо Debian (вероятно, я опубликую вопрос о том, какую ОС использовать в качестве сервера - я уже знаком с Ubuntu)

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

Чтобы не размещать все важные ключи шифрования на сервере веб-сайта, который также может быть взломан в какой-то момент, я бы сделал следующее:

1. Внутренний сервер резервного копирования на собственном сайте клиента - имеет ключи шифрования и ключи SSH для обоих других серверов
2. Сервер, на котором размещен сайт - может быть хостом
3. Облачный резервный сервер или сервис

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

• Я бы использовал rsnapshot через SSH, используя основанный на ключах вход в систему, поскольку это требует минимальных требований к веб-хосту и внутреннему серверу резервного копирования - если у вас нет большой базы данных для резервного копирования, она очень эффективна в полосе пропускания и хранит несколько версий сайта, а также занимается очисткой старых резервных копий.
• Шифрование может быть выполнено любым инструментом «файл-файл», таким как GPG, копируя дерево rsnapshot в другое дерево, или вы можете использовать двуличие для шага 2, экономя место на диске.
• Важное значение имеет «извлечение» с сервера резервного копирования - если на главном сервере (2) есть пароли / ключи для сервера резервного копирования, хакеры могут, а иногда и удаляют резервные копии после взлома основного сервера (см. Ниже). Действительно продвинутые хаки могут установить троянские двоичные файлы SSH, которые могут затем скомпрометировать сервер резервного копирования, но это менее вероятно для большинства компаний.

Шаг 2: сервер (1) помещает зашифрованные резервные копии в (3) для создания резервной копии за пределами площадки. Если резервные копии были зашифрованы на шаге 1, вы можете просто использовать rsync-зеркало локального дерева rsnapshot для удаленной системы.

• Duplicity - это хороший вариант для прямого шифрования и резервного копирования незашифрованного дерева rsnapshot на удаленный сервер. Функции Duplicity немного отличаются от rsnapshot, использующего архивы tar с GPG-шифрованием, но он обеспечивает резервное шифрование на удаленном хосте и требует только SSH на этом хосте (или он может использовать Amazon S3). Duplicity не поддерживает жесткие ссылки , поэтому, если это требуется (например, для полной резервной копии сервера), лучше всего, если скрипт преобразует дерево rsnapshot (которое поддерживает жесткие ссылки) в файл tar (может быть, только в файлы, которые имеют> 1 жесткая ссылка, которая будет довольно маленькой), так что двуличие может создать резервную копию файла tar.
• Поскольку удаленный сервер является просто хостом SSH, возможно, с rsync, он может быть веб-хостом (но от другого хостинг-провайдера и в другой части страны) или облачной службой, которая предоставляет rsync и / или SSH - см. этот ответ о резервном копировании rsync в облако для рекомендации bqbackup и rsync.net, хотя я не согласен с упомянутой настройкой резервного копирования.
• Вы можете использовать Amazon S3 в качестве удаленного сервера с дублированием, что обеспечит вам действительно хорошую доступность, хотя, возможно, это будет стоить дороже для больших резервных копий.
• Другими вариантами удаленного зашифрованного резервного копирования являются Boxbackup (не совсем зрелый, некоторые приятные функции) и Tarsnap (коммерческий облачный сервис на основе Amazon S3 с простым интерфейсом командной строки, хорошей дедупликацией и очень тщательным шифрованием).
  • JungleDisk может быть вариантом, но у меня не было большого опыта с ними в прошлом, и у их шифрования есть некоторые проблемы (от автора Tarsnap).

Безопасность всех различных хостов важна, поэтому ее следует настроить в соответствии с профилем безопасности клиента, т. Е. Проанализировать угрозы, риски, векторы атак и т. Д. Ubuntu Server - неплохой старт, поскольку он часто обновляет систему безопасности в течение 5 лет. лет, но внимание к безопасности требуется на всех серверах.

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

• Независимые резервные копии имеют решающее значение, поскольку хакеры действительно иногда удаляют все резервные копии одновременно со взломом сайта - в самом последнем случае хакеры уничтожили 4800 веб-сайтов, включая резервные копии , взломав среду веб-хостинга, а не сайты. Смотрите также этот ответ и этот .
• Восстановить с rsnapshot очень просто - в каждом дереве снимков есть по одному файлу для каждого файла, для которого выполняется резервное копирование, поэтому просто найдите файлы с помощью инструментов Linux и rsync или отправьте их обратно на веб-сайт. Если по какой-либо причине локальный сервер резервного копирования недоступен, просто используйте двуличность для восстановления их с облачного сервера резервного копирования - или вы можете использовать стандартные инструменты, такие как GPG, rdiff и tar, для восстановления резервных копий.

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

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

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

Когда я создаю систему для своих клиентов, я использую rsync с ключами SSH для обработки аутентификации между сервером A и сервером B, где serverA содержит данные, подлежащие резервному копированию. Команда для архивирования и rsync данных содержится в bash-скрипте в недоступном для веб-каталога каталоге, который вызывается cron каждые H часов (24 для ежедневных и т. Д. И т. Д.)

Сервер резервного копирования, serverB, должен использоваться ТОЛЬКО для резервного копирования. Я всегда советую своим клиентам использовать очень длинный пароль с аутентификацией по ключу SSH, чтобы можно было загружать резервные копии и создавать резервные копии. Иногда моим клиентам необходимо сохранять резервные копии в течение D дней, поэтому я пишу несколько сценариев для их обработки (взять данные из активного каталога резервных копий, применить временную метку, добавить в архив в другом каталоге).

Для малого бизнеса / просумера я бы порекомендовал Amazon Storage Service .

• Контроль региона (т.е. объекты, хранящиеся в ЕС, никогда не покидают ЕС).
• 99,9% времени безотказной работы для любого данного цикла выставления счетов
• $ 0,150 за ГБ хранится в месяц
• $ 0,170 за загруженный ГБ
• Бесплатная загрузка до июня 2010 года, $ 0,10 за ГБ после этого

И довольно расплывчатая уверенность в том, что «предусмотрены механизмы аутентификации для обеспечения безопасности данных от несанкционированного доступа».

В то время как bluenovember находится на правильном пути с S3, система Amazon на самом деле не является решением для резервного копирования с резервированием, это решение для хранения необработанных данных, для которого все еще требуется использование внешней системы для резервного копирования, будь то несколько вызовов API или полный пакет управления резервным копированием. Что-то вроде JungleDisk Server Edition , которая использует S3 на бэкэнде, но обеспечивает лучший интерфейс для использования в качестве решения для резервного копирования, вероятно, было бы лучше.

Кроме того, JungleDisk предоставит вам встроенное шифрование, что вам нужно будет добавить независимо от того, как вы планируете подключиться к S3 / «облаку». У них также есть довольно приятное клиентское программное обеспечение для Linux.

Мне нравится хранить свою резервную копию в Amazon AWS, и я использую бесплатный инструмент s3cmd ( http://s3tools.org/s3cmd )

Его можно установить довольно легко (Debian: apt-get install s3cmd).

Все, что вам нужно для учетной записи Amazon AWS, чтобы хранить ваши файлы на S3. Затем простая команда может запустить резервное копирование, даже инкрементное или как решение для синхронизации, например:

s3cmd sync /srv/backup  s3://your-bucket-name-at-amazon/

Убедитесь, что вы бежите

s3cms --configure 

сначала введите свои учетные данные AWS.