Я планирую использовать Amazon S3 для хранения наших обычных резервных копий SQL. Я хотел бы знать, рекомендуется ли загружать резервную копию после локального создания или создавать ее непосредственно на S3. Я думаю, что в случае заражения программой-вымогателем было бы более безопасно загружать файлы вместо сопоставления корзины S3 с сервером (используя, например, Tntdrive), но я хотел бы знать ваши рекомендации по этой теме.
С уважением.
Мы используем VEEAM для этой цели, как описано здесь. http://veeam.com/blog/leverage-vtl-on-amazon-aws-object-storage-s3-glacier.html со StarWind VTL для AWS http://www.starwindsoftware.com/starwind-cloud-vtl-for-veeam.
В этой настройке используются как S3, так и Glacier с использованием интеллектуальных политик хранения, где вы можете точно настроить, как долго ваши резервные копии будут оставаться локально, и указать количество времени, в течение которого резервные копии будут отправляться в хранилище Glacier.
Очевидно, вы можете использовать любое программное обеспечение для резервного копирования, которое поддерживает виртуальные ленты. Формат VTL может показаться странным, но на самом деле он дает два больших преимущества. Виртуальная лента, являющаяся объектом, отлично работает с облачным хранилищем, которое тоже основано на объектах. И он не поражен программами-вымогателями (что доказано недавней эпидемией Petya.A).
Я бы не стал подключать диск напрямую к S3, если вас беспокоят вирусы или программы-вымогатели, даже если версии корзины могут защитить от повреждения. Если ваше программное обеспечение для резервного копирования может создавать файлы непосредственно в S3 с помощью API, тогда да, сделайте это. Если нет, то вам, вероятно, придется создать файл локально, а затем загрузить его.
Довольно легко создать пользователя IAM с разрешениями только для загрузки в одну корзину без удаления или другого доступа. Вы можете использовать коммерческое программное обеспечение или инструменты командной строки AWS. Если это будет полезно, у меня есть политики и сценарии IAM, которыми я могу поделиться.
Если вы запускаете сервер dB самостоятельно и на EC2, почему бы просто не сделать снимок диска, на котором вы сбрасываете dB, с помощью согласованных с Amazon инструментов моментальных снимков. Он использует то же пространство, что и дифференциальный, и, поскольку он находится на уровне диска, не имеет путей к вирусам за пределами виртуализации xen.
Я не вижу проблем с загрузкой резервных копий SQL непосредственно в S3. Почему бы и нет, если вы можете это сделать. Либо через интерфейс командной строки AWS, либо через сторонние приложения для резервного копирования.
Кроме того, я думаю, у вас есть тома EBS, подключенные к вашему экземпляру EC2. Увеличить IOPS для ваших БД. Не так ли? Если да, вы можете создавать снимки ваших томов. Которые будут храниться в S3 и будут иметь инкрементный характер.
Что касается двойной стойкости - воспользуйтесь функцией AWS S3 Cross-region replication.
Надеюсь, это поможет вам принять решение.
Я создаю резервную копию своих данных непосредственно в корзине S3 с помощью инструмента резервного копирования Cloudberry, и поскольку передаваемые данные зашифрованы, а S3 также имеет свои собственные функции безопасности, нет ничего страшного в атаке программ-вымогателей на резервные копии данных. Кроме того, поставщики облачных хранилищ используют избыточную настройку хранилища, поэтому для любых таких ситуаций аварийного восстановления существует несколько копий резервных данных.