Я понимаю, как работает rsync на высоком уровне, но есть две стороны. В S3 нет демона, о котором можно было бы говорить - ну, он есть, но в основном это просто HTTP.
Есть несколько подходов.
s3rsync (но это просто болты на rsync к s3). Просто. Не уверен, что хочу зависеть от чего-то третьего. Я бы хотел, чтобы s3 поддерживал только rsync.
Также есть некоторые «клоны» rsync, такие как duplicity, которые утверждают, что поддерживают s3 без упомянутых болтов. Но как это сделать? Хранят ли они индексный файл локально? Я не уверен, как это может быть так эффективно.
Я, очевидно, хочу использовать s3, потому что он дешевый и надежный, но есть вещи, для которых rsync является инструментом, например, резервное копирование гигантского каталога изображений.
Какие здесь варианты? Что я теряю, используя duplicity + s3 вместо rsync + s3rsync + s3?
Поскольку на этот вопрос был дан последний ответ, появился новый инструмент командной строки AWS, aws.
Это может синхронизировать, как rsync, между локальным хранилищем и s3. Пример использования:
aws s3 sync s3://mybucket /some/local/dir/
Если среда Python вашей системы настроена правильно, вы можете установить клиент AWS, используя pip:
pip install awscli
В инструмент s3cmd имеет большой sync вариант. Я использую его для синхронизации локальных резервных копий, например:
s3cmd sync --skip-existing $BACKUPDIR/weekly/ s3://MYBACKUP/backup/mysql/
В --skip-existing означает, что он не пытается сравнивать контрольную сумму существующих файлов. Если файл с таким именем уже существует, он просто быстро его пропустит и продолжит. А также есть --delete-removed опция, которая удалит файлы, не существующие локально, но я хочу сохранить на S3 даже те, которые я очистил локально, поэтому я не использую это.
Не хочу никому указывать, что делать, но могу ли я помахать флагом за двуличие? или другое решение для инкрементного резервного копирования. С синхронизацией все в порядке, но если вы делаете резервную копию каждую ночь, что произойдет, если вы не заметите проблемы в течение двух дней? Ответ: Слишком поздно, ваши локальные файлы и резервная копия являются зеркалом друг друга и не имеют нужных вам данных. Вам действительно следует рассмотреть возможность создания инкрементных резервных копий или моментальных снимков, чтобы вы могли восстановиться до определенного момента времени, и для того, чтобы делать это эффективно, вам нужны добавочные резервные копии. И если потеря ваших данных - это сценарий конца света, храните копии у разных поставщиков, о чем вы никогда не узнаете, а затем можете потеряться, взломать, кто знает.
Я использую duplicity и s3, это нормально, но требует много ресурсов процессора. Но он делает инкрементное резервное копирование. В экстренной ситуации, когда вы хотите восстановить каталог или конкретный файл, как это было в прошлую среду или в прошлом январе, без восстановления других файлов в том же разделе, вам понадобятся инкрементные резервные копии и инструмент, с помощью которого вы можете запросить только те файлы, которые вам нужны.
У меня есть cron, который заполняется каждые x месяцев, в противном случае инкрементный и удаляет более x месяцев, чтобы сохранить общие объемы хранилища s3, наконец, статус сбора, поэтому я получаю по почте каждое утро со статусом. Вам нужно регулярно следить за ним, чтобы вы могли заметить, когда ваша резервная копия не работает.
Для хранения локальных подписей требуется значительное локальное временное пространство, поэтому внимательно настройте временный каталог. Это резервные копии / mnt, за исключением различных каталогов внутри / mnt. Это хорошо для резервного копирования данных, для системных разделов используйте инструменты Amazon Image или Snapshot.
Скрипт PHP:
# Duplicity Backups
$exclude = "--exclude /mnt/ephemeral ".
"--exclude /mnt/logs ".
"--exclude /mnt/service ".
"--exclude /mnt/mail ".
"--exclude /mnt/mysql ";
$key = "PASSPHRASE=securegpgpassphrase";
$tmp = "/mnt/mytempdir";
system("mkdir -p $tmp");
# Amazon
$aws = "AWS_ACCESS_KEY_ID=xxxxxx ".
"AWS_SECRET_ACCESS_KEY=xxxxxx ";
$ops = "-v5 --tempdir=$tmp --archive-dir=$tmp --allow-source-mismatch --s3-european-buckets --s3-use-new-style --s3-use-rrs";
$target = " s3://s3-eu-west-1.amazonaws.com/mybucket";
# Clean + Backup
system("$key $aws /usr/bin/duplicity $ops --full-if-older-than 2M $exclude /mnt $target");
system("$key $aws /usr/bin/duplicity $ops remove-older-than 6M --force $target");
system("$key $aws /usr/bin/duplicity $ops cleanup --force --extra-clean $target");
system("$key $aws /usr/bin/duplicity $ops collection-status $target")
В качестве альтернативы вы можете использовать клиент minio aka MC Использование команды «mc mirror» выполнит эту работу.
$ mc mirror share/sharegain/ s3/MyS3Bucket/share/sharegain
Вы можете написать простой сценарий cronjob, который будет выполнять синхронизацию через определенные промежутки времени.
Надеюсь, поможет.
S3 - это система хранения объектов общего назначения, которая обеспечивает достаточную гибкость для разработки того, как вы хотите ее использовать.
Из вашего вопроса я не уверен, что проблемы с rsync (кроме индексации) или проблемы со сторонним инструментом, с которым вы столкнулись.
Если у вас есть большой набор хорошо структурированных файлов, вы можете запустить несколько s3-синхронизаций в своих подпапках.
Хорошие ребята из Amazon также позволяют вам делать импорт / экспорт с портативного жесткого диска для передачи больших файлов на S3 или EBS - http://aws.amazon.com/importexport/ который вы можете использовать для первой загрузки.
См. Лучшие практики Amazon s3 здесь - http://aws.amazon.com/articles/1904
Что касается различных инструментов, попробуйте их и посмотрите, что лучше всего подходит для вас. Что касается цен, то цена за резервирование снижается, если она соответствует вашим потребностям - http://aws.amazon.com/s3/pricing/
Общая рекомендация - имейте быстрый многоядерный процессор и хороший сетевой канал.
ОБНОВЛЕНИЕ: упоминание о контрольной сумме на S3
Что касается S3, данные хранятся в парах ключ-значение, и здесь нет понятия каталогов. S3sync проверяет контрольную сумму (у S3 есть механизм отправки контрольной суммы в качестве заголовка для проверки - заголовок Content-MD5). Лучшие практики связывают целостность данных, в той части, где это подробно описано. S3 позволяет отправлять / проверять и получать контрольные суммы. Многие люди делают инкрементные резервные копии двулично. Несмотря на то, что на S3 нет rsync, вы можете делать контрольные суммы, как я упоминал здесь.
rsync - проверенный инструмент, и большинство современных инструментов используют тот же алгоритм или библиотеку rsync или вызывают rsync извне.
Я не уверен, что истинный rsync подходит для Amazon.
Насколько я понимаю, стандартный алгоритм rsync означает, что клиент вычисляет хэши для каждого блока файла, а сервер вычисляет хэши для своей копии и отправляет эти хэши клиенту, что означает, что клиент может определить, какие блоки были изменены и нуждаются в загрузке.
Это вызывает две проблемы для Amazon: большое количество хэшей необходимо отправлять через Интернет, а также требуется вычислительная мощность для вычисления всех этих хэшей, которые увеличивают затраты Amazon - вероятно, поэтому они оставляют это сторонним поставщикам, которые могут взимать дополнительную плату за эту функцию.
Что касается клонов, очевидно, что они где-то хранят хеши, и это место может варьироваться в зависимости от клона. Они могли бы хранить хэши как отдельный объект для каждого файла на Amazon или как базу данных, хранящуюся на Amazon, или они могут хранить их локально и удаленно.
В любом случае есть свои преимущества и недостатки. Если хэши хранятся удаленно в отдельных файлах, их постоянное получение может оказаться дорогостоящим. Если хэши хранятся в базе данных удаленно, эта база данных может стать большой, и их постоянное извлечение и обновление может быть дорогостоящим. Если хэши хранятся локально, это помогает снизить затраты, но создает другие сложности и проблемы.
(Конечно, у Amazon есть другие сервисы, поэтому можно было бы хранить базу данных в БД Amazon)
Например, много лет назад я опробовал один ранний клон rsync. Это не было написано с учетом структуры ценообразования Amazon и выдавало множество HTTP-запросов для получения хэша каждого блока, и, поскольку Amazon взимает плату за каждое получение, это означало, что, хотя часть моего счета за хранение резко упала, часть передачи надутый.
Что я теряю, используя duplicity + s3 вместо rsync + s3rsync + s3?
Вы теряете тот факт, что с помощью rsync вы знаете, что сравниваете исходные файлы с файлами резервных копий. С дублированием и другими клонами вы сравниваете свои исходные файлы с хешем, который был взят при выполнении резервного копирования. Например, можно получить прямой доступ к S3 и заменить один из его файлов без повторного вычисления хеша или обновления базы данных хешей.
После сравнения нескольких вариантов, упомянутых в этой теме, я решил выбрать S3fs. Он позволяет монтировать S3 как локальную файловую систему. Затем вы можете продолжить и использовать rsync так, как вы это уже знаете.
Это хорошее руководство для начала: Amazon S3 с Rsync
Автор ранее использовал упомянутый s3sync, но затем перешел на вариант с S3Fs. Мне это нравится, потому что у меня также есть другие резервные папки, подключенные локально через SSHFS.