Примечание: Резервное копирование данных, хранящихся на Amazon S3 похожа, но довольно старая и не соответствует общепринятой практике.
Наш сервис предполагает, что каждый пользователь загружает пару файлов. Сотни тысяч пользователей будут продолжать расти.
Мы используем AWS для нашей инфраструктуры, и в настоящее время все файлы выгружаются и хранятся непосредственно в S3. Папка верхнего уровня занимает около 75 ГБ и продолжает расти.
В течение долгого времени у нас был скрипт, который делает ночное резервное копирование, копируя каждый файл через S3 API в другую папку. В последние несколько месяцев стоимость хранения стала огромной, поэтому мы перешли на хранение резервных копий только раз в две недели.
Причина хранения резервных копий заключается в том, что бизнес зависит от загружаемых пользователем данных. Подумайте о Dropbox, Flickr или Giphy.
Мы не беспокоимся о потере данных S3, а скорее из-за человеческая ошибка, что более вероятно независимо от того, сколько мер предосторожности мы принимаем. В таких случаях мы должны иметь возможность восстановить данные до определенного момента времени.
Однако стратегия резервного копирования S3 кажется сомнительной, поскольку кажется, что резервное копирование происходит некорректно. Размер резервных копий иногда кажется очень низким, что означает, что операции копирования S3 не работают - даже использование веб-консоли S3 для копирования-вставки папки с большим количеством файлов не работает должным образом и зависает после частичного завершения, заставляет нас еще больше подозревать операции с большими копиями на S3.
Нам известно о версиях объектов S3, но это не кажется правильным решением для резервного копирования, чтобы смягчить последствия человеческой ошибки, такие как удаление корзины.
Какую стратегию резервного копирования файлов используют компании, которые зависят от файлов, загруженных пользователями?
Типичные стратегии включают:
Включение управления версиями сегментов сохранит версии файлов в случае перезаписи и удаления. В этом случае вы можете восстановить предыдущую версию файла.
Включение MFA-удаления потребует от кого-то использовать ключ MFA каждый раз, когда они хотят удалить файлы. Случайное удаление в этом случае очень сложно.
Удаление корзины невозможно, если она содержит данные. Итак, чтобы удалить корзину, кому-то нужно сначала удалить все файлы.
Вы можете стать сильнее, добавив к нему политику корзины, предотвращающую s3:DeleteObject команда. При этом удаление объектов запрещено на уровне корзины; никто не сможет удалить объекты, даже если у них есть разрешения и устройство MFA.
Еще одна вещь, которую вы можете сделать, - это скопировать ваши файлы в другую корзину. Используя правила жизненного цикла, ваши объекты могут автоматически дублироваться в другой сегмент в другом регионе ежедневно.
TL; DR, управления версиями корзины и удаления MFA обычно достаточно для предотвращения случайной потери данных. Только злоумышленник действительно может уничтожить данные. Но вы также можете защитить свое ведро с помощью политики ведра.
Я бы никогда не доверил всю свою критически важную информацию одному поставщику или одному месту. S3 хранит файлы в нескольких местах с одним регионом, что защищает только от сбоев оборудования.
У меня есть несколько идей.
Если бы у меня было время подумать, я бы, наверное, придумал больше вариантов. Ваши RTO и RPO действительно будут способствовать решению.