forum.opennet.ru - "межоблачный бэкап" (10)

"межоблачный бэкап"

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

"межоблачный бэкап"	+/–
Сообщение от 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ообщить модератору

Оглавление

админ ссдэк а , pavel_simple. (?), 20:27 , 28-Май-24, (1) +1

gt оверквотинг удален я нет а по существу есть что сказать , Alexander (ok), 09:10 , 29-Май-24, (2) –1

Скрыто модератором, Аноним (-), 10:04 , 29-Май-24, (3)

Скрыто модератором, Alexander (ok), 11:44 , 29-Май-24, (4)

Добрый день Прочитал твой вопрос и тут-же возник встречный вопрос почему не рас, Аноним (5), 14:56 , 29-Май-24, (5)

Судя по требованиям HIPAA compliance на форуме opennet, речь идет о страховых ме, Дополнение (?), 15:15 , 29-Май-24, (6)

Нет, речь совсем не про РФ, Alexander (ok), 19:46 , 29-Май-24, (8)

Ленточный бэкап где У того же AWS или в другом месте Если AWS - то проблема ос, Alexander (ok), 19:45 , 29-Май-24, (7)

Не зная общей архитектуры трудно что-либо посоветовать Очень приблизительно, авт, Аноним (5), 20:45 , 29-Май-24, (9)

Думаю, хранение бэкапов у двух разных клауд-провайдеров вполне покрывает описанн, Alexander (ok), 10:39 , 30-Май-24, (10)

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

1. "межоблачный бэкап" +1 +/–

Сообщение от pavel_simple. (?), 28-Май-24, 20:27

> (Я изначально ошибся 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. "межоблачный бэкап" –1 +/–

Сообщение от Alexander (ok), 29-Май-24, 09:10

>[оверквотинг удален]
>> сюда - сорри за дубликат)
>> Добрый день.
>> Посоветуйте, пожалуйста, решение от какого-нибудь крупного вендора (чтобы был 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ообщить модератору

3. Скрыто модератором +/–

Сообщение от Аноним (-), 29-Май-24, 10:04

Сначала присядут на вендора по самые помидоры, а потом думают, как присесть ещё на одного вендора, и ведь всё им рассказали про EEE, объяснили, зачем нужны традиционные инструменты бэкапа, но нет, надо взять у вендора, ведь у вендора вкусно.

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

4. Скрыто модератором +/–

Сообщение от Alexander (ok), 29-Май-24, 11:44

> Сначала присядут на вендора по самые помидоры, а потом думают, как присесть
> ещё на одного вендора, и ведь всё им рассказали про EEE,
> объяснили, зачем нужны традиционные инструменты бэкапа, но нет, надо взять у
> вендора, ведь у вендора вкусно.
у вендора не вкусно, а комплаенсно. в регулируемых отраслях без этого никак.

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

5. "межоблачный бэкап" +/–

Сообщение от Аноним (5), 29-Май-24, 14:56

Добрый день!
Прочитал твой вопрос и тут-же возник встречный вопрос: почему не рассматривается ленточный бэкап в дополнение к облачному? При надлежащем выборе решения, "ХИПА" будет только рада. Да и использование различных сред хранения бэкапов дает сильный + к надежности.

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

6. "межоблачный бэкап" +/–

Сообщение от Дополнение (?), 29-Май-24, 15:15

Судя по требованиям HIPAA compliance на форуме opennet, речь идет о страховых медицинских данных российских граждан(?).
В нынешних условиях достаточно велик риск возникновения изолированого "чебурнета" (учения уже были). Можно разом потерять доступ ко всем бэкапам на западных "облаках". Старый добрый ленточный стриммер полностью нивелирует эти риски.

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

8. "межоблачный бэкап" +/–

Сообщение от Alexander (ok), 29-Май-24, 19:46

> Судя по требованиям HIPAA compliance на форуме opennet, речь идет о страховых
> медицинских данных российских граждан(?).
Нет, речь совсем не про РФ

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

7. "межоблачный бэкап" +/–

Сообщение от Alexander (ok), 29-Май-24, 19:45

> Добрый день!
> Прочитал твой вопрос и тут-же возник встречный вопрос: почему не рассматривается ленточный
> бэкап в дополнение к облачному? При надлежащем выборе решения, "ХИПА" будет
> только рада. Да и использование различных сред хранения бэкапов дает сильный
> + к надежности.
Ленточный бэкап где? У того же AWS или в другом месте? Если AWS - то проблема остается: при случайном удалении эккаунта, данные на лентах тоже удалятся. Если в другом месте, то по-прежнему надо понять чем бэкапить.

Ответить | Правка | К родителю #5 | Наверх | Cообщить модератору

9. "межоблачный бэкап" +/–

Сообщение от Аноним (5), 29-Май-24, 20:45

> Ленточный бэкап где? У того же AWS или в другом месте?
Не зная общей архитектуры трудно что-либо посоветовать.
Очень приблизительно, автоматическая ленточная библиотека размещается в изолированном сегменте на us-east-1. Если площадка арендована, значит дополнительно покупать юниты для colocation. Бэкап в облако продолжает независимо жить.
> AWS - то проблема остается: при случайном удалении эккаунта, данные на
> лентах тоже удалятся
Стриммер и ленты должны быть своими (не в аренде). Это единственная гарантия от "взбрыков" облачных провайдеров. Кстати, и от шифровальщиков тоже (ленты в библиотеке физически ротируются)
>Задумался об этом, прочитав статью как Гугл случайно удалил данные клиента
Это - респект!

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

10. "межоблачный бэкап" +/–

Сообщение от Alexander (ok), 30-Май-24, 10:39

> Очень приблизительно, автоматическая ленточная библиотека размещается в изолированном
> сегменте на us-east-1. Если площадка арендована, значит дополнительно покупать юниты для
> colocation. Бэкап в облако продолжает независимо жить.
>> AWS - то проблема остается: при случайном удалении эккаунта, данные на
>> лентах тоже удалятся
> Стриммер и ленты должны быть своими (не в аренде). Это единственная гарантия
> от "взбрыков" облачных провайдеров. Кстати, и от шифровальщиков тоже (ленты в
> библиотеке физически ротируются)
Думаю, хранение бэкапов у двух разных клауд-провайдеров вполне покрывает описанный риск. Свои ленты - это, конечно, хорошо, но, на мой взгляд, не сопоставимо по стоимости и сложности обслуживания. От шифровальщиков ленты спасают ровно так же, как и обычные write-only бэкапы.
Спасибо вам за совет!

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

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

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

Партнёры:

Хостинг:

Закладки на сайте
Проследить за страницей

Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру

1. "межоблачный бэкап"	+1 +/–
Сообщение от pavel_simple. (?), 28-Май-24, 20:27
> (Я изначально ошибся 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. "межоблачный бэкап"	–1 +/–
	Сообщение от Alexander (ok), 29-Май-24, 09:10
	>[оверквотинг удален] >> сюда - сорри за дубликат) >> Добрый день. >> Посоветуйте, пожалуйста, решение от какого-нибудь крупного вендора (чтобы был 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ообщить модератору

3. Скрыто модератором	+/–
Сообщение от Аноним (-), 29-Май-24, 10:04
Сначала присядут на вендора по самые помидоры, а потом думают, как присесть ещё на одного вендора, и ведь всё им рассказали про EEE, объяснили, зачем нужны традиционные инструменты бэкапа, но нет, надо взять у вендора, ведь у вендора вкусно.
Ответить \| Правка \| Наверх \| Cообщить модератору


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

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


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


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


	7. "межоблачный бэкап"	+/–
	Сообщение от Alexander (ok), 29-Май-24, 19:45
	> Добрый день! > Прочитал твой вопрос и тут-же возник встречный вопрос: почему не рассматривается ленточный > бэкап в дополнение к облачному? При надлежащем выборе решения, "ХИПА" будет > только рада. Да и использование различных сред хранения бэкапов дает сильный > + к надежности. Ленточный бэкап где? У того же AWS или в другом месте? Если AWS - то проблема остается: при случайном удалении эккаунта, данные на лентах тоже удалятся. Если в другом месте, то по-прежнему надо понять чем бэкапить.
	Ответить \| Правка \| К родителю #5 \| Наверх \| Cообщить модератору


	9. "межоблачный бэкап"	+/–
	Сообщение от Аноним (5), 29-Май-24, 20:45
	> Ленточный бэкап где? У того же AWS или в другом месте? Не зная общей архитектуры трудно что-либо посоветовать. Очень приблизительно, автоматическая ленточная библиотека размещается в изолированном сегменте на us-east-1. Если площадка арендована, значит дополнительно покупать юниты для colocation. Бэкап в облако продолжает независимо жить. > AWS - то проблема остается: при случайном удалении эккаунта, данные на > лентах тоже удалятся Стриммер и ленты должны быть своими (не в аренде). Это единственная гарантия от "взбрыков" облачных провайдеров. Кстати, и от шифровальщиков тоже (ленты в библиотеке физически ротируются) >Задумался об этом, прочитав статью как Гугл случайно удалил данные клиента Это - респект!
	Ответить \| Правка \| Наверх \| Cообщить модератору


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