Как мне синхронизировать папку с одного тома EBS на другой для того же EC2?

У меня есть экземпляр EC2 с прикрепленными к нему томами EBS A и B, и я хочу скопировать / реплицировать / синхронизировать данные из определенной папки в EBS A в EBS B.

EBS A - это основной том, на котором размещаются данные установки приложения и пользовательские данные, и я хочу эффективно создать резервную копию пользовательских данных (которые представляют собой просто определенный каталог) в EBS B на тот случай, если установка приложения будет повреждена или ее необходимо восстановить. сдулся. Таким образом, я могу просто установить новый EC2 с новой первичной EBS, назвать его C, присоединить к нему EBS B и протолкнуть пользовательские данные из EBS B в EBS C.

Я использую Amazon Linux 2 и уже прошел процесс форматирования и монтирования резервной копии EBS. Я могу вручную скопировать данные из EBS A в EBS B, но я надеялся, что кто-то может указать мне на передовые методы синхронизации данных каталога между двумя томами?

Я нашел рекомендации для rsync, задачи cron и gluster для аналогичных случаев использования. Будет ли хорошей практикой использовать один из них для моего варианта использования?


amazon-web-services aws-ebs
person Tikiyetti    schedule 16.05.2019    source источник

Ответы (1)


arrow_upward
2
arrow_downward

Хотя вы можете использовать rsync, лучшей альтернативой является Data Lifecycle Manager, который будет делать автоматические снимки состояния EBS.

Причина, по которой это лучше, заключается в том, что вы можете указать фиксированное количество снимков с фиксированным интервалом времени, поэтому вам не нужно восстанавливать последнее (это важно, если «текущие» данные повреждены).

Чтобы использовать это наиболее эффективно, я бы отделил загрузочный том от томов приложений / данных. Таким образом, вы можете просто восстановить снимок, запустить новый экземпляр и подключить к нему восстановленный том.

person guest    schedule 16.05.2019
comment
К счастью, у меня уже есть загрузочный том как отдельный том. Основная причина, по которой я изначально не использовал этот подход, заключается в том, что, если бы я восстановил полный том из более раннего снимка, я бы тоже потерял дельту в пользовательских данных. Вот почему я пытаюсь отделить данные пользователя от данных приложения. В противном случае да, я бы выбрал DLM. Если только ... Может ли он делать снимки определенных папок на томе, или это должен быть полный том? - person Tikiyetti; 16.05.2019
comment
@Tikiyetti - снимает весь том. Но если вам нужно отслеживать пользовательские данные отдельно, они всегда могут идти в отдельном объеме. - person guest; 16.05.2019
comment
Способ работы со снимками - одна из самых крутых частей EBS: это действительно моментальный снимок тома на определенный момент времени, основанный (насколько я могу судить) на записи списка неизменяемых идентификаторов блоков, которые представляют данные на томе. . В результате создание нескольких моментальных снимков обходится очень дешево, поскольку они записывают только отличия от предыдущего моментального снимка. И нет никакого состояния гонки, как если бы вы rsync пытались записать файлы, которые могут изменяться под ним. - person guest; 16.05.2019
comment
Итак, в моем случае, так как я бы сдул исходную EBS с данными приложения / пользователя, а полный снимок / резервная копия все равно будет содержать данные пользователя ... Я также могу просто сделать инкрементные снимки всего объем, и если мне нужно сдуть и восстановить, я всегда могу выбрать, какие папки я беру из снимка, верно? Потому что мне могут не нужны данные приложения (возможно, поврежденные) из этого снимка, но мне нужны данные пользователя. Вот как я это понимаю на эластике. - person Tikiyetti; 17.05.2019
comment
@Tikiyetti - это действительно зависит от того, как вы хотите структурировать свои тома. У вас могут быть отдельные тома для данных приложения и пользователя, но это может быть больше накладных расходов на управление, чем вы хотите. Но определенно да для частых инкрементальных снимков. - person guest; 17.05.2019