Як вибрати хмарний сервіс для резервного копіювання

Я думаю використовувати хмарний сервіс для резервного копіювання одного з веб-сайтів мого клієнта.

Мої (клієнти) основні проблеми (у порядку зменшення важливості)

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 у віддаленій системі.

• Дублікати було б хорошим варіантом безпосередньо зашифрувати та створити резервну копію незашифрованого дерева rsnapshot на віддалений сервер. Особливості Duplicity дещо відрізняються від rsnapshot, використовуючи зашифровані 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 .

• Регіональний контроль (тобто об'єкти, що зберігаються в ЄС, ніколи не залишають ЄС).
• 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.