Я размещаю 200 ГБ изображений продуктов на S3 (это мой основной файловый хост).
Нужно ли мне делать резервную копию этих данных в другом месте, или S3 и так безопасен?
Я экспериментировал с установкой корзины S3 на экземпляр EC2, а затем делал ночную резервную копию rsync. Проблема в том, что это около 3 миллионов файлов, поэтому для создания различных потребностей rsync требуется время. На самом деле резервное копирование занимает около 3 дней.
Есть идеи, как это сделать лучше? (если это вообще необходимо?)
Я занимаюсь этим исследованием, достаточно забавно.
Ваши резервные копии на S3 могут завершиться ошибкой в зависимости от вашего региона из-за возможной согласованности; основное предупреждение заключается в том, что если вы сделаете это достаточно, в какой-то момент у вас возникнут ошибки при открытии или поиске файлов, поскольку волшебство файловой системы в фоновом режиме Amazon синхронизируется между серверами, поэтому ваши резервные копии могут быть ненадежными.
Что касается того, нужно ли вам спасти их другим способом, это зависит от вашего управления рисками. Вы доверяете Amazon хранить ваши данные?
Возможно, они что-то потеряют или имеют более серьезный сбой в системе хранения; у них, несомненно, есть пункты в их контрактах, указывающие, что если они потеряют ваши данные, это ваш проблема. Не их. Кроме того, поскольку ваши данные хранятся где-то еще, вы не знаете, что они будут с ними делать; правоохранительные органы хотят ваши данные? Вы можете даже не знать, что кто-то другой получил к нему доступ.
Вы ему доверяете? Если данные не являются ключевыми для вашего бизнеса, и вы готовы принять этот риск, то нет необходимости загружать их во внешнее хранилище. Если вы не хотите рисковать, что ваши данные будут в безопасности на серверах хранения Amazon, вам следует принять меры для периодического сброса их в собственное хранилище.
Другими словами, я не думаю, что на это есть однозначный ответ, поскольку это зависит от вашей терпимости к риску и потребностей бизнеса. Многие люди не будут полностью доверять свои доходы исключительно облачным хранилищам, лично я немного опасаюсь этого ...
Чтобы сделать это лучше, в обсуждениях и исследованиях следует рассмотреть еще один подход: создать том EBS, достаточно большой для хранения данных, присоединить его к экземпляру EC2, сохранить там свои данные, затем вы можете размонтировать том и сохранить эти данные на S3. . Я нахожусь в процессе исследования, будет ли это сделано как сохранение самого файла тома на S3 или его содержимого ... но затем вы можете удалить экземпляр EBS, когда это будет сделано, чтобы сэкономить на хранении.
РЕДАКТИРОВАТЬ При перечитывании я вижу, что вы сохраняете ОТ S3 В экземпляр EC2, а не наоборот (хотя я не знаю, может ли проблема с согласованностью вызвать проблемы). Вы пытаетесь сохранить данные в инстансе EC2 в качестве резервной копии? Я считаю, что с точки зрения затрат это неразумная тактика; резервное копирование данных на локальный диск может оказаться дешевле, если вы учитываете долгосрочное хранение таких данных, а также время виртуальной машины. С затратами на диски вы можете копировать данные на локальный диск в качестве резервной копии.
Я бы все равно сохранил предупреждения о доверии Amazon и их хранилищу. Если вы хотите сохранить все в Amazon S3, но иметь большую избыточность, продублируйте свои корзины S3 в разных регионах, и если у них есть сбой, затрагивающий один регион, он не должен выбивать их все. Вы бы надеялись. Но все возможно.
Все сводится к тому, насколько вы цените свои данные, сколько готовы за них платить и с каким риском вы готовы мириться.
Я использовал s3cmd's s3cmd sync сделать это. Это немного похоже на rsync в своей работе и может перемещать и извлекать целые каталоги между S3 и другой системой Linux по вашему выбору.
Я не вижу причин, по которым ты не мог s3cmd sync к работающему экземпляру EC2 или даже вашей собственной рабочей станции разработчика (или серверу хранения).
Возможно, вы захотите настроить экземпляр VPC, а затем назначить небольшому узлу внутри вашего VPC роль резервного сервера и присвоить ему IP-адрес внутри сети Amazon, а также внутри вашей локальной подсети.
Мой совет: ваши данные - это ваша ответственность, а не Amazon. Если потеря данных не такая уж большая проблема, не делайте резервную копию самостоятельно. Если это так, то сделайте свою резервную копию (по крайней мере) на дешевый JBOD (и регулярно проверяйте), как это делаю я.
Вы узнаете, какую ответственность Amazon готов взять на себя за ваши данные в тот день, когда они их потеряют.
Если вы можете себе это позволить (как я это делаю), все мои данные хранятся на моем сервере, но извлекаются из Amazon s3. Поэтому, если Amazon выйдет из строя по какой-либо причине (коснитесь дерева), я могу просто мгновенно вытащить все свои данные прямо со своего сервера. Со своего сервера я делаю ежемесячные резервные копии на свой локальный диск. Поскольку мой веб-сайт занимает более 2 ТБ.
Хотя это старый поток, это первое, что возникает при поиске в Google резервной копии S3, поэтому я подумал, что добавлю к нему ...
Проведя небольшое исследование по этому поводу, я обнаружил Rclone https://rclone.org/ - это программное обеспечение в стиле rsync, предназначенное для копирования между службами облачного хранения файлов и поддерживающее большинство из них. Никакой принадлежности, и я еще не использовал его, поэтому не могу сказать, хорошо это или плохо, но я подумал, что это может кому-то помочь.
Мне кажется, что есть возможность для размещенной службы, которая выполняет резервное копирование файлов, размещенных в облаке (S3, Google Storage, Rackspace Cloud Files и т. Д.) ...