Инкрементное резервное копирование сервера в Ледник AWS
Я говорю все это не используя Резервное копирование Windows Server, поэтому возьмите его если это имеет значение. Многое из этого собирается зависеть от того, как это записывает данные обратно к диску. Если необходимо восстановить ОС, следовать за направлениями здесь. При предположении, что базы данных не находятся на диске ОС (говорят мне, у Вас есть отдельные данные и диски журнала) затем калибровка не должна иметь значения слишком много здесь.
Я не вижу, что что-либо расценивает размеры кластера форматирования в моих поисках, таким образом предполагая, что лучший случай вот - то, что я попробовал бы. Разбудите ОС и выполнение, и затем используйте DISKPART (или перейдите к diskmgmt, безотносительно) для форматирования данных управляйте способом, которым Вы хотите. Затем используйте WSB для записи данных в диск, не форматируя его.
Другой вещью рассмотреть вот является состояние дисков, которые Вы восстанавливаете. Если аппаратные средства прекрасны, но у Вас просто было повреждение данных, то можно просто восстановить объем, не переформатировав так или иначе. Если аппаратные средства разложились, необходимо будет подготовить их прежде, чем восстановить данные.
Все это, чтобы сказать, что я не нашел способ изменить размер кластера во время самого восстановления.
Итак, что произойдет, если я загружу файл / архив, а затем файл изменится локально, и в следующий раз, когда я сделаю резервную копию, как Glacier справится с это, поскольку он не может перезаписать файл новой версией?
Согласно FAQ по Glacier :
Вы храните данные в Amazon Glacier в виде архива. Каждому архиву присваивается уникальный идентификатор архива, который впоследствии можно использовать для извлечения данных. Архив может представлять собой один файл или вы можете объединить несколько файлов для загрузки в один архив. Вы загружаете архивы в хранилища. Хранилища - это коллекции архивов, которые вы используете для организации своих данных.
Это означает, что каждому загружаемому файлу назначается уникальный идентификатор. Загрузите один и тот же файл дважды, и каждая копия файла получит свой собственный идентификатор. Это дает вам возможность при желании восстановить предыдущие версии файла.
Использовать локально сохраненную инвентаризацию архива, чтобы определить, какие данные больше не существуют, и если им больше 3 месяцев, удалить их из Glacier? Это кажется простым, но есть ли лучший подход к этому?
Это, вероятно, лучший подход, чтобы избежать дополнительной платы за удаление данных, которым меньше трех месяцев. Но вам нужно отслеживать и удалять не только данные, которых больше не существует. Как упоминалось выше, каждый раз, когда файл изменяется и вы повторно загружаете его в Glacier, вы получаете новый идентификатор файла. В конечном итоге вы захотите удалить и более старые версии файла, предполагая, что вам не нужна возможность восстановления до этих более старых версий.
Если загружен zip-файл размером 20 МБ, содержащий 10 000 файлов, и один из этих файлов изменен локально, мне нужно загрузить еще один zip-файл размером 20 МБ? Теперь мне нужно съесть затраты на хранение 2 копий почти всего в этих zip-файлах ... Кроме того, как я буду справляться с удалением вещей в ZIP-файле, которые больше не существуют локально? Поскольку я не хочу удалять весь zip-файл, теперь я беру плату за хранение файлов, которые больше не существуют.
Это компромисс, который вам действительно нужно решить для себя. Вы заархивируете / заархивируете все, а затем будете вынуждены отслеживать эти файлы и все в них, или вам стоит загружать файлы по отдельности, чтобы вы могли очищать их по отдельности, поскольку они больше не нужны.
Вы можете рассмотреть несколько других подходов:
- иметь два или более tar / zip архивов, один содержит файлы, которые вряд ли будут изменены (например, системные файлы), а другой (ы) содержит файлы конфигурации и другие вещи, которые с большей вероятностью изменятся со временем.
- Не беспокойтесь об отслеживании отдельных файлов и сохраните все в одном архиве tar / zip, который загружается в Glacier. Когда каждый архив достигает трехмесячного срока (или, возможно, даже позже), просто удалите его. Это дает вам очень простой способ отслеживать и восстанавливать данные с заданного момента времени.
Однако, несмотря на все это, Glacier может быть не лучшим подходом для ваших нужд. Glacier действительно предназначен для архивирования данных, которое отличается от простого резервного копирования серверов. Если вы просто хотите делать инкрементные резервные копии сервера, то использование S3 вместо Glacier может быть лучшим подходом. Использование такого инструмента, как Duplicity или rdiff-backup (в сочетании с чем-то вроде s3fs ), даст вам возможность создавать инкрементные резервные копии в ведре S3 и управлять их очень легко. Я использовал rdiff-backup на нескольких Linux-системах за эти годы и обнаружил, что он работает довольно хорошо.
В качестве альтернативы можно использовать нечто вроде Дубликации, а затем загружать создаваемые ею архивы.
Это имеет несколько преимуществ:
- Дублиность делает инкрементные бэкапы, поэтому только измененные файлы перехватываются в наборе резервных копий
- Дубличность может справиться с изменениями файлов, поэтому если изменяется только небольшая часть файла, то теоретически загружается только изменение
- Ваши бэкапы шифруются, если вы параноик типа
Самый простой способ использовать Duplicity с Glacier это:
- Резервное копирование в локальный каталог где-нибудь (и хранить эту резервную копию). Дубликации нужен доступ к своему "манифестному" файлу каждый раз при запуске резервной копии, чтобы она могла определить, какие файлы изменились.
- Загружайте любые новые архивы, созданные Duplicity на Glacier из вашей локальной резервной копии. Для этого используйте что-нибудь вроде glacier-cmd.
Вот инструмент командной строки для * nix, который поддерживает загрузку только измененных файлов, замена локально измененных файлов и удаление локально удаленных файлов из Glacier https://github.com/vsespb/mt-aws-glacier