Я думаю об использовании облачной службы для резервного копирования одного из веб-сайтов моего клиента.
Основные проблемы моих (клиентов) (в порядке убывания важности)
В идеале я хотел бы, чтобы услуга не была слишком длительной (т.е. я бы предпочел услугу с оплатой по мере использования)
Я также хотел бы избежать привязки к поставщику, когда практически невозможно перейти на другой сервис.
Я хотел бы получить общие рекомендации по:
Серверное программное обеспечение будет либо Ubuntu, либо Debian (я, вероятно, опубликую вопрос о том, какую ОС использовать в качестве сервера - я уже знаком с Ubuntu)
Любое решение, которое не включает шифрование на стороне клиента с ключами, принадлежащими владельцу, не будет соответствовать первому заявленному требованию (IP-защита / безопасность) - любой взлом на стороне сервера раскрывает незашифрованные данные. Это исключает системы облачной синхронизации, такие как Dropbox, которым принадлежат ключи.
Чтобы избежать размещения важнейших ключей шифрования на сервере веб-сайта, который также может быть взломан в какой-то момент, я бы сделал следующее:
Шаг 1. Сервер (1) извлекает резервную копию из (2), поэтому большинство взломов сервера веб-сайта не повлияют на резервные копии. На этом этапе происходит шифрование.
Шаг 2: сервер (1) отправляет зашифрованные резервные копии в (3), чтобы создать резервную копию. Если резервные копии были зашифрованы на шаге 1, вы можете просто использовать rsync-зеркало локального дерева rsnapshot для удаленной системы.
Безопасность всех различных хостов важна, поэтому ее следует отрегулировать в соответствии с профилем безопасности клиента, то есть анализировать угрозы, риски, векторы атак и т. Д. Ubuntu Server - неплохое начало, так как он имеет частые обновления безопасности для 5 лет, но на всех серверах требуется внимание к безопасности.
Эта установка обеспечивает 2 независимых резервных копии, одна из которых может быть облачным хранилищем с высокой доступностью, работает в режиме извлечения, поэтому большинство атак на веб-сайт не могут уничтожить резервные копии одновременно, и в нем используются проверенные инструменты с открытым исходным кодом, которые не требуют много администрирования.
Поскольку в этой настройке используются стандартные SSH и rsync, должно быть проще выбрать подходящего поставщика с надлежащими гарантиями бесперебойной работы, надежной безопасностью и т. Д. сбой, у вас все еще есть локальная резервная копия, и вы можете легко переключиться на другую службу резервного копирования.
Программно, рассмотрите двуличие для инкрементных резервных копий с асимметричным шифрованием и «глупым» приемником (не облачным как).
Я всегда говорю своим клиентам, что лучшее, наименее дорогое и наиболее эффективное решение для резервного копирования - это то, что вы создаете сами для своих целей.
Когда я создаю систему для своих клиентов, я использую rsync с ключами SSH для обработки аутентификации между serverA и serverB, где serverA содержит данные для резервного копирования. Команда для архивации и rsync данных содержится в сценарии bash в каталоге, не доступном через Интернет, который вызывается cron каждые H часов (24 часа в день и т. Д.).
Сервер резервного копирования, serverB, должен использоваться ИСКЛЮЧИТЕЛЬНО для резервного копирования. Я всегда советую своим клиентам использовать очень длинный пароль с аутентификацией по ключу SSH, чтобы разрешить загрузку резервных копий и резервное копирование. Иногда моим клиентам требуется, чтобы резервные копии сохранялись в течение D дней, поэтому я пишу несколько сценариев, чтобы справиться с этим (взять данные из активного каталога резервных копий, применить временную метку, добавить в архив в другом каталоге).
В то время как bluenovember находится на правильном пути с S3, система Amazon на самом деле не является решением для резервного копирования, это решение для хранения необработанных данных, которое по-прежнему требует использования клиентской системы для резервного копирования, будь то несколько вызовов API или полный пакет управления резервным копированием. Что-то вроде Серверная версия JungleDisk, который использует S3 на сервере, но предоставляет лучший интерфейс для использования в качестве решения для резервного копирования, вероятно, будет лучше.
Вдобавок JungleDisk предоставит вам встроенное шифрование, которое вам нужно будет добавить независимо от того, как вы планируете подключаться к S3 / «облаку». У них также есть довольно приятное клиентское программное обеспечение для Linux.
Для малого бизнеса / просьюмера я бы рекомендовал Служба хранения Amazon.
И довольно расплывчатая уверенность в том, что «предусмотрены механизмы аутентификации для защиты данных от несанкционированного доступа».
Мне нравится хранить резервную копию в 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.