Як можна ефективно використовувати S3 для поступового резервного копіювання файлів?

Я розумію, як rsync працює на високому рівні, але є 2 сторони. З S3 немає демона, про який можна говорити - ну є, але в основному це лише HTTP.

Існує кілька підходів.

s3rsync (але це просто підключення rsync до s3). Прямо. Не впевнений, що хочу залежати від чогось третьої сторони. Я хочу, щоб s3 просто підтримував rsync.

Існують також деякі "клони" rsync, такі як подвійність, які стверджують, що підтримують 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, його штрафом, але він є інтенсивним процесором. Але це робить додаткові резервні копії. У надзвичайних ситуаціях, коли ви хочете відновити dir або певний файл, як це було минулої середи або минулого січня, не відновлюючи інші файли на тому самому розділі, вам потрібні додаткові резервні копії та інструмент, де ви можете запитувати лише потрібні файли.

У мене є крон, який працює повноцінно кожні x місяці, інакше наростаючий і видаляє старше x місяців, щоб зменшити загальний обсяг пам’яті s3, нарешті, статус колекції зменшується, тому я щоранку отримую повідомлення зі статусом. Вам потрібно регулярно стежити за цим, щоб ви помітили, коли ваша резервна копія не працює.

Для збереження локальних підписів таким чином потрібно ретельно налаштувати темп реж. Це резервне копіювання / mnt, виключаючи різні dir всередині / mnt. Це добре для резервного копіювання даних, для системних розділів використовуйте інструменти для зображень Amazon або знімків.

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")

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 дозволяє надсилати / перевіряти та отримувати контрольні суми. Є багато людей, які роблять резервні копії з подвійністю. Хоча rsync не працює на S3, ви можете робити контрольні суми, як я вже згадував тут.

rsync - це перевірений інструмент, і більшість сучасних інструментів використовують той самий алгоритм або бібліотеку rsync або викликають rsync зовні.

Ви також можете використовувати minio client aka mc Використання команди 'mc mirror' зробить цю роботу.

$ mc mirror share/sharegain/ s3/MyS3Bucket/share/sharegain 

• mc: міні-клієнт
• share / sharegain: локальний каталог
• s3: Псевдонім для https://s3.amazonaws.com
• MyS3Bucket: Мій віддалений відро S3
• share / sharegain: Мій об’єкт на s3

Ви можете написати простий сценарій як cronjob, який буде підтримувати синхронізацію з періодичним інтервалом.

Сподіваюся, це допомагає.

Я не впевнений, чи справжня rsync підходить для Amazon.

Як я розумію, стандартний алгоритм rsync означає, що клієнт обчислює хеші для кожного блоку файлу, а сервер обчислює хеші для його копії та надсилає ці хеші клієнту, а це означає, що клієнт може визначити, які блоки змінилися та потребують завантаження.

Це спричиняє дві проблеми для Amazon в тому, що багато хешей потрібно надсилати через Інтернет, а також потрібна обробна потужність, щоб обчислити всі ті хеші, які б збільшили витрати Amazon. за цю функцію стягується додаткова плата.

Що стосується клонів, вони, очевидно, зберігають хеші десь і десь можуть змінюватися залежно від клону. Вони можуть зберігати хеші як окремий об'єкт у файлі на Amazon або у базі даних, що зберігається на Amazon, або вони можуть зберігати їх локально та віддалено.

Є переваги і недоліки робити це будь-яким способом. Якщо хеші зберігаються віддалено в окремих файлах, то їх постійне відновлення може бути дорогим. Якщо хеші зберігаються в базі даних віддалено, то ця база може набути великих масштабів, а їх постійне відновлення та оновлення може бути дорогим. Якщо хеші зберігаються локально, то це сприяє зменшенню витрат, але створює інші ускладнення та проблеми.

(Звичайно, в Amazon є інші сервіси, тому можна було б зберігати базу даних у Amazon DB)

Як приклад, я спробував один ранній клон rsync багато років тому. Це було написано не для врахування структури ціноутворення в Amazon, і було видано багато http, щоб отримати хеш кожного блоку, і оскільки стягнення Amazon за кожне отримання, це означало, що, хоча частина зберігання мого рахунку різко впала, частина передачі повітряна куля.

Що я втрачаю, використовуючи duplicity + s3 замість rsync + s3rsync + s3?

Ви втрачаєте той факт, що за допомогою rsync ви знаєте, що порівнюєте вихідні файли з вашими резервними файлами. З подвійністю та іншими клонами ви порівнюєте вихідні файли з хешем, який був зроблений під час резервного копіювання. Наприклад, можливо отримати доступ до S3 безпосередньо та замінити один із його файлів без перекомпонування хешу чи оновлення хеш-бази даних.

Після порівняння кількох варіантів, згаданих у цій темі, я вирішив перейти до S3fs. Це дозволяє монтувати S3 як локальну файлову систему. Потім ви можете продовжити та використовувати rsync так, як ви це вже знаєте.

Це хороший підручник для початку роботи: Amazon S3 з Rsync

Автор раніше використовував згаданий s3sync, але потім перейшов до параметра з S3F. Мені це подобається, тому що у мене також є інші резервні папки, локально встановлені через SSHFS.