The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]



"межоблачный бэкап"
Вариант для распечатки  
Пред. тема | След. тема 
Форум Открытые системы на сервере (Резервное копирование)
Изначальное сообщение [ Отслеживать ]

"межоблачный бэкап"  +/
Сообщение от Alexander (ok), 28-Май-24, 14:14 
(Я изначально ошибся c разделом форума, а модератор так и не перенес сюда - сорри за дубликат)

Добрый день.

Посоветуйте, пожалуйста, решение от какого-нибудь крупного вендора (чтобы был HIPAA- и SOC2-compliant) для резервного копирования данных из AWS в любое другое облако (Azure/GCP/IBM/etc). Данные лежат в RDS (mysql), EFS, S3 и EBS (Cassandra). Понятно, что проще и дешевле скриптами все сделать, но скрипты к "ХИПЕ" не подошьешь :)

PS Задумался об этом, прочитав статью как Гугл случайно удалил данные клиента без возможности восстановления (https://arstechnica.com/gadgets/2024/05/google-cloud-acciden.../)

Ответить | Правка | Cообщить модератору

Оглавление

Сообщения [Сортировка по ответам | RSS]

1. Сообщение от pavel_simple. (?), 28-Май-24, 20:27   +1 +/
> (Я изначально ошибся c разделом форума, а модератор так и не перенес
> сюда - сорри за дубликат)
> Добрый день.
> Посоветуйте, пожалуйста, решение от какого-нибудь крупного вендора (чтобы был HIPAA- и
> SOC2-compliant) для резервного копирования данных из AWS в любое другое облако
> (Azure/GCP/IBM/etc). Данные лежат в RDS (mysql), EFS, S3 и EBS (Cassandra).
> Понятно, что проще и дешевле скриптами все сделать, но скрипты к
> "ХИПЕ" не подошьешь :)
> PS Задумался об этом, прочитав статью как Гугл случайно удалил данные клиента
> без возможности восстановления (https://arstechnica.com/gadgets/2024/05/google-cloud-acciden.../)

админ ссдэк'а?

Ответить | Правка | Наверх | Cообщить модератору
Ответы: #2

2. Сообщение от Alexander (ok), 29-Май-24, 09:10   –1 +/
>[оверквотинг удален]
>> сюда - сорри за дубликат)
>> Добрый день.
>> Посоветуйте, пожалуйста, решение от какого-нибудь крупного вендора (чтобы был HIPAA- и
>> SOC2-compliant) для резервного копирования данных из AWS в любое другое облако
>> (Azure/GCP/IBM/etc). Данные лежат в RDS (mysql), EFS, S3 и EBS (Cassandra).
>> Понятно, что проще и дешевле скриптами все сделать, но скрипты к
>> "ХИПЕ" не подошьешь :)
>> PS Задумался об этом, прочитав статью как Гугл случайно удалил данные клиента
>> без возможности восстановления (https://arstechnica.com/gadgets/2024/05/google-cloud-acciden.../)
> админ ссдэк'а?

я? нет. а по существу есть что сказать?

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #1

3. Сообщение от Аноним (-), 29-Май-24, 10:04    Скрыто ботом-модератором+/
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #4

4. Сообщение от Alexander (ok), 29-Май-24, 11:44   +/
> Сначала присядут на вендора по самые помидоры, а потом думают, как присесть
> ещё на одного вендора, и ведь всё им рассказали про EEE,
> объяснили, зачем нужны традиционные инструменты бэкапа, но нет, надо взять у
> вендора, ведь у вендора вкусно.

у вендора не вкусно, а комплаенсно. в регулируемых отраслях без этого никак.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #3

5. Сообщение от Аноним (5), 29-Май-24, 14:56   +/
Добрый день!
Прочитал твой вопрос и тут-же возник встречный вопрос: почему не рассматривается ленточный бэкап в дополнение к облачному? При надлежащем выборе решения, "ХИПА" будет только рада. Да и использование различных сред хранения бэкапов дает сильный + к надежности.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #6, #7

6. Сообщение от Дополнение (?), 29-Май-24, 15:15   +/
Судя по требованиям HIPAA compliance на форуме opennet, речь идет о страховых медицинских данных российских граждан(?).
В нынешних условиях достаточно велик риск возникновения изолированого "чебурнета" (учения уже были). Можно разом потерять доступ ко всем бэкапам на западных "облаках". Старый добрый ленточный  стриммер полностью нивелирует эти риски.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #5 Ответы: #8

7. Сообщение от Alexander (ok), 29-Май-24, 19:45   +/
> Добрый день!
> Прочитал твой вопрос и тут-же возник встречный вопрос: почему не рассматривается ленточный
> бэкап в дополнение к облачному? При надлежащем выборе решения, "ХИПА" будет
> только рада. Да и использование различных сред хранения бэкапов дает сильный
> + к надежности.

Ленточный бэкап где? У того же AWS или в другом месте? Если AWS - то проблема остается: при случайном удалении эккаунта, данные на лентах тоже удалятся. Если в другом месте, то по-прежнему надо понять чем бэкапить.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #5 Ответы: #9

8. Сообщение от Alexander (ok), 29-Май-24, 19:46   +/
> Судя по требованиям HIPAA compliance на форуме opennet, речь идет о страховых
> медицинских данных российских граждан(?).

Нет, речь совсем не про РФ

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #6

9. Сообщение от Аноним (5), 29-Май-24, 20:45   +/
> Ленточный бэкап где? У того же AWS или в другом месте?

Не зная общей архитектуры трудно что-либо посоветовать.

Очень приблизительно, автоматическая ленточная библиотека размещается в изолированном сегменте на us-east-1. Если площадка арендована, значит дополнительно покупать юниты для colocation. Бэкап в облако продолжает независимо жить.

> AWS - то проблема остается: при случайном удалении эккаунта, данные на
> лентах тоже удалятся

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

>Задумался об этом, прочитав статью как Гугл случайно удалил данные клиента

Это - респект!

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #7 Ответы: #10

10. Сообщение от Alexander (ok), 30-Май-24, 10:39   +/
> Очень приблизительно, автоматическая ленточная библиотека размещается в изолированном
> сегменте на us-east-1. Если площадка арендована, значит дополнительно покупать юниты для
> colocation. Бэкап в облако продолжает независимо жить.
>> AWS - то проблема остается: при случайном удалении эккаунта, данные на
>> лентах тоже удалятся
> Стриммер и ленты должны быть своими (не в аренде). Это единственная гарантия
> от "взбрыков" облачных провайдеров. Кстати, и от шифровальщиков тоже (ленты в
> библиотеке физически ротируются)

Думаю, хранение бэкапов у двух разных клауд-провайдеров вполне покрывает описанный риск. Свои ленты - это, конечно, хорошо, но, на мой взгляд, не сопоставимо по стоимости и сложности обслуживания. От шифровальщиков ленты спасают ровно так же, как и обычные write-only бэкапы.

Спасибо вам за совет!

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #9


Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема




Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей
Created 1996-2025 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру