https://opennet.ru/openforum/vsluhforumID1/97976.html (Я изначально ошибся c разделом форума, а модератор так и не перенес сюда - сорри за дубликат)<br><br>Добрый день.<br><br>Посоветуйте, пожалуйста, решение от какого-нибудь крупного вендора (чтобы был HIPAA- и SOC2-compliant) для резервного копирования данных из AWS в любое другое облако (Azure/GCP/IBM/etc). Данные лежат в RDS (mysql), EFS, S3 и EBS (Cassandra). Понятно, что проще и дешевле скриптами все сделать, но скрипты к "ХИПЕ" не подошьешь :)<br><br>PS Задумался об этом, прочитав статью как Гугл случайно удалил данные клиента без возможности восстановления (https://arstechnica.com/gadgets/2024/05/google-cloud-accidentally-nukes-customer-account-causes-two-weeks-of-downtime/)<br> https://opennet.ru/openforum/vsluhforumID1/97976.html#10 Thu, 30 May 2024 07:39:40 GMT &gt; Очень приблизительно, автоматическая ленточная библиотека размещается в изолированном <br>&gt; сегменте на us-east-1. Если площадка арендована, значит дополнительно покупать юниты для <br>&gt; colocation. Бэкап в облако продолжает независимо жить.<br>&gt;&gt; AWS - то проблема остается: при случайном удалении эккаунта, данные на <br>&gt;&gt; лентах тоже удалятся <br>&gt; Стриммер и ленты должны быть своими (не в аренде). Это единственная гарантия <br>&gt; от "взбрыков" облачных провайдеров. Кстати, и от шифровальщиков тоже (ленты в <br>&gt; библиотеке физически ротируются) <br><br>Думаю, хранение бэкапов у двух разных клауд-провайдеров вполне покрывает описанный риск. Свои ленты - это, конечно, хорошо, но, на мой взгляд, не сопоставимо по стоимости и сложности обслуживания. От шифровальщиков ленты спасают ровно так же, как и обычные write-only бэкапы.<br><br>Спасибо вам за совет!<br> https://opennet.ru/openforum/vsluhforumID1/97976.html#9 Wed, 29 May 2024 17:45:45 GMT &gt; Ленточный бэкап где? У того же AWS или в другом месте?<br><br>Не зная общей архитектуры трудно что-либо посоветовать.<br><br>Очень приблизительно, автоматическая ленточная библиотека размещается в изолированном сегменте на us-east-1. Если площадка арендована, значит дополнительно покупать юниты для colocation. Бэкап в облако продолжает независимо жить.<br><br>&gt; AWS - то проблема остается: при случайном удалении эккаунта, данные на <br>&gt; лентах тоже удалятся<br><br>Стриммер и ленты должны быть своими (не в аренде). Это единственная гарантия от "взбрыков" облачных провайдеров. Кстати, и от шифровальщиков тоже (ленты в библиотеке физически ротируются)<br><br>&gt;Задумался об этом, прочитав статью как Гугл случайно удалил данные клиента<br><br>Это - респект!<br> https://opennet.ru/openforum/vsluhforumID1/97976.html#8 Wed, 29 May 2024 16:46:09 GMT &gt; Судя по требованиям HIPAA compliance на форуме opennet, речь идет о страховых <br>&gt; медицинских данных российских граждан(?).<br><br>Нет, речь совсем не про РФ<br> https://opennet.ru/openforum/vsluhforumID1/97976.html#7 Wed, 29 May 2024 16:45:10 GMT &gt; Добрый день!<br>&gt; Прочитал твой вопрос и тут-же возник встречный вопрос: почему не рассматривается ленточный <br>&gt; бэкап в дополнение к облачному? При надлежащем выборе решения, "ХИПА" будет <br>&gt; только рада. Да и использование различных сред хранения бэкапов дает сильный <br>&gt; + к надежности.<br><br>Ленточный бэкап где? У того же AWS или в другом месте? Если AWS - то проблема остается: при случайном удалении эккаунта, данные на лентах тоже удалятся. Если в другом месте, то по-прежнему надо понять чем бэкапить.<br> https://opennet.ru/openforum/vsluhforumID1/97976.html#6 Wed, 29 May 2024 12:15:34 GMT Судя по требованиям HIPAA compliance на форуме opennet, речь идет о страховых медицинских данных российских граждан(?).<br>В нынешних условиях достаточно велик риск возникновения изолированого "чебурнета" (учения уже были). Можно разом потерять доступ ко всем бэкапам на западных "облаках". Старый добрый ленточный стриммер полностью нивелирует эти риски.<br> https://opennet.ru/openforum/vsluhforumID1/97976.html#5 Wed, 29 May 2024 11:56:08 GMT Добрый день!<br>Прочитал твой вопрос и тут-же возник встречный вопрос: почему не рассматривается ленточный бэкап в дополнение к облачному? При надлежащем выборе решения, "ХИПА" будет только рада. Да и использование различных сред хранения бэкапов дает сильный + к надежности.<br> https://opennet.ru/openforum/vsluhforumID1/97976.html#4 Wed, 29 May 2024 08:44:54 GMT &gt; Сначала присядут на вендора по самые помидоры, а потом думают, как присесть <br>&gt; ещё на одного вендора, и ведь всё им рассказали про EEE, <br>&gt; объяснили, зачем нужны традиционные инструменты бэкапа, но нет, надо взять у <br>&gt; вендора, ведь у вендора вкусно.<br><br>у вендора не вкусно, а комплаенсно. в регулируемых отраслях без этого никак.<br><br> https://opennet.ru/openforum/vsluhforumID1/97976.html#3 Wed, 29 May 2024 07:04:14 GMT Сначала присядут на вендора по самые помидоры, а потом думают, как присесть ещё на одного вендора, и ведь всё им рассказали про EEE, объяснили, зачем нужны традиционные инструменты бэкапа, но нет, надо взять у вендора, ведь у вендора вкусно.<br> https://opennet.ru/openforum/vsluhforumID1/97976.html#2 Wed, 29 May 2024 06:10:20 GMT &gt;[оверквотинг удален]<br>&gt;&gt; сюда - сорри за дубликат) <br>&gt;&gt; Добрый день.<br>&gt;&gt; Посоветуйте, пожалуйста, решение от какого-нибудь крупного вендора (чтобы был HIPAA- и <br>&gt;&gt; SOC2-compliant) для резервного копирования данных из AWS в любое другое облако <br>&gt;&gt; (Azure/GCP/IBM/etc). Данные лежат в RDS (mysql), EFS, S3 и EBS (Cassandra).<br>&gt;&gt; Понятно, что проще и дешевле скриптами все сделать, но скрипты к <br>&gt;&gt; "ХИПЕ" не подошьешь :) <br>&gt;&gt; PS Задумался об этом, прочитав статью как Гугл случайно удалил данные клиента <br>&gt;&gt; без возможности восстановления (https://arstechnica.com/gadgets/2024/05/google-cloud-accidentally-nukes-customer-account-causes-two-weeks-of-downtime/) <br>&gt; админ ссдэк'а?<br><br>я? нет. а по существу есть что сказать?<br>