Comments 51
Меня смутило: "… иногда после потери сетевого соединения с хранилищем… ". Насколько часто такое «иногда» случается?
Необходимость восстанавливать подключение хранилища к серверу после каких-либо падений вручную не вызываем оптимизма :-(.
Необходимость восстанавливать подключение хранилища к серверу после каких-либо падений вручную не вызываем оптимизма :-(.
Спасибо за наводку. Судя по документации — s3ql поддерживает разные хранилища, например бесплатный (с бесплатной квотой) Google Storage
Есть еще два вопроса:
1. Подскажите, распределяете ли вы копии данных между датацентрами? Было бы здорово, чтобы три копии оказывались в разных ДЦ.
2. Не смог найти по этой услуге SLA.
И одна ремарка — на сайте стоило выложить договор оферты, чтобы можно было четко понять все организационно-правовые нюансы.
1. Подскажите, распределяете ли вы копии данных между датацентрами? Было бы здорово, чтобы три копии оказывались в разных ДЦ.
2. Не смог найти по этой услуге SLA.
И одна ремарка — на сайте стоило выложить договор оферты, чтобы можно было четко понять все организационно-правовые нюансы.
Договоры есть на сайте:http://selectel.ru/about/documents/.
А как всё это дело хранится в самом хранилище? Сейчас использую для тех же целей cloudfuse, откровенно говоря совсем недоволен. Как мигрировать?
На самом хранилище это всё выглядит как куча мелких шифрованых файлов с максимальным размером --max-obj-size, который был указан при mkfs.s3ql.
Для перехода вам надо скачать все данные из текущего контейнера и скопировать их на файловую систему s3ql, просто скопировать данные между контейнерами не получится.
Для перехода вам надо скачать все данные из текущего контейнера и скопировать их на файловую систему s3ql, просто скопировать данные между контейнерами не получится.
Насколько понял не поддерживаются снэпшоты, это верно? Хотелось бы аналог команды: <zfs shapshot -r>
Это чтоже прямо rsync-ом бэкапы можно делать?
Только что попробовал. Сабж реально работает.
Но должен сказать, что есть облачные хранилища, поддерживающие rsync напрямую.
Вот, к примеру, несколько:
— s3rsync.com
— gogrid.com/products/infrastructure-cloud-storage
— www.onlinestoragesolution.com/features.html
— cloudstorage.olbiz.net/support/backup-your-web-site-server-rsync
— www.bqbackup.com/
— www.rsync.net/
— dreamhost.com/cloud/dreamobjects/
— dreamhost.com/cloud/dreamobjects/
Но должен сказать, что есть облачные хранилища, поддерживающие rsync напрямую.
Вот, к примеру, несколько:
— s3rsync.com
— gogrid.com/products/infrastructure-cloud-storage
— www.onlinestoragesolution.com/features.html
— cloudstorage.olbiz.net/support/backup-your-web-site-server-rsync
— www.bqbackup.com/
— www.rsync.net/
— dreamhost.com/cloud/dreamobjects/
— dreamhost.com/cloud/dreamobjects/
хочется быть ближе к земле.
Почему? Не вижу причины, кроме разве что необходимости в отчетных документах.
Но можно быть еще ближе — поставить дома NAS с выделенным IP и бэкапиться на него. Эх, я бы так и делал, если бы не запланированный на ближайшие месяцы переезд.
Но можно быть еще ближе — поставить дома NAS с выделенным IP и бэкапиться на него. Эх, я бы так и делал, если бы не запланированный на ближайшие месяцы переезд.
причина в большем доверии к Селектелу и Амазону,
чем, скажем, к s3rsync, котрый перепродаёт s3 амазона, или cloudstorage.olbiz.net, котрый вообще непонятно что со ссылками на другие сайты.
чем, скажем, к s3rsync, котрый перепродаёт s3 амазона, или cloudstorage.olbiz.net, котрый вообще непонятно что со ссылками на другие сайты.
Как Amazon и Selectel могут для вас быть земляками одновременно?
s3rsync.com — это шлюз между Amazon S3 и вашим rsync-клиентом. Они ничего не перепродают, только оказывают услугу. Место на Amazon надо оплачивать самому.
Суть наезда на olbiz.net не понял.
Я не пытаюсь защищать перечисленные сервисы. Я только дал понять, что есть решения, поддерживающие rsync напрямую, а не через виртуальную файловую систему, которая лишает вас возможности пользоваться вэб-интерфейсом хранилища.
s3rsync.com — это шлюз между Amazon S3 и вашим rsync-клиентом. Они ничего не перепродают, только оказывают услугу. Место на Amazon надо оплачивать самому.
Суть наезда на olbiz.net не понял.
Я не пытаюсь защищать перечисленные сервисы. Я только дал понять, что есть решения, поддерживающие rsync напрямую, а не через виртуальную файловую систему, которая лишает вас возможности пользоваться вэб-интерфейсом хранилища.
Попробовал сабж. Действительно работает и действительно очень просто!
В пакете для Ubuntu маленькая проблемка — не прописана одна из зависимостей. Так что устанавливать нужно так:
К сожалению, использование сабжа делает невозможным просмотр и скачивание файлов через вэб-интерфейс Selectel. :( Получается вот такая каша:
akme, вы ведь реализуете поддержку сабжа в вашем вэб-интерфейсе, правда?
В пакете для Ubuntu маленькая проблемка — не прописана одна из зависимостей. Так что устанавливать нужно так:
aptitude install s3ql python-pkg-resourcesК сожалению, использование сабжа делает невозможным просмотр и скачивание файлов через вэб-интерфейс Selectel. :( Получается вот такая каша:
akme, вы ведь реализуете поддержку сабжа в вашем вэб-интерфейсе, правда?
не прописана одна из зависимостей. Так что устанавливать нужно так:
Что, простите? Aptitude в убунте разучился решать зависимости?
packages.ubuntu.com/precise/s3ql
Тут вроде все на месте?
Нет, поддержку веб-интерфейса для s3ql мы делать не будем.
Почему? :(
Всего-то надо проверять контейнер на наличие файла, например, s3ql_metadata.txt, монтировать ФС и считывать его содержимое оттуда.
Всего-то надо проверять контейнер на наличие файла, например, s3ql_metadata.txt, монтировать ФС и считывать его содержимое оттуда.
Хотя бы потому что s3ql, к сожалению, не рассчитан на распределенную работу, поэтому любые изменения через веб-панель могут привести к порче или потере данных.
То есть одновременное монтирование сабжа из двух разных мест не будет ограничено, но приведет к потере данных? =-O
Кем ограничено? Нами не будет, потому что s3ql всего-лишь клиентский софт, а клиент волен делать что хочет. А сам s3ql не рассчитан на более чем одно активное монтирование.
А кто-нибудь использует s3ql в продакшне с большими объемами на хорошей нагрузке? Как там с надежностью, с сохранностью данных? Я на amazon S3 пару раз сталкивался с тем, что при неудачном размонтировании, или жестком ребуте виртуалки, где примонтирован s3ql, при повторном монтировании просит сделать fsck, мотивируя тем, что система уже примонтирована. Делаю fsck, а он удаляет все файлы, что там есть.
Ох… Звучит ужасно. Особенно имея в виду, что я начал использовать сабж для хранения бэкапов.
Значит, надо монтировать перед началом заливки бэкапов и размонтировать сразу после.
Интересно, что скажет представитель Selectel по поводу этого:
www.rath.org/s3ql-docs/durability.html
Значит, надо монтировать перед началом заливки бэкапов и размонтировать сразу после.
Интересно, что скажет представитель Selectel по поводу этого:
www.rath.org/s3ql-docs/durability.html
Можно быть уверенными, что все переданные данные в Хранилище надежно сохраняются и хранятся, это гарантируется на уровне API и самом устройстве системы.
Главное чтобы сам s3ql залил все нужные данные и метаданные. Монтирование и потом размонтирование на время бэкапа будет более надежным, как раз потому что s3ql в таком случае синхронизирует все данные.
Главное чтобы сам s3ql залил все нужные данные и метаданные. Монтирование и потом размонтирование на время бэкапа будет более надежным, как раз потому что s3ql в таком случае синхронизирует все данные.
Надежность хранилища никто под сомнение не ставит, вопрос не в этом. Вопрос в том, как надежно сам s3ql закачивает, модифицирует и удаляет файлы, как обрабатывает нештатные ситуации, какие меры в нем приняты, чтобы информация в хранилище осталась цела в случае внезапной потери связи, или резета сервера. Может-быть кто-нибудь гонял его на стресс-тестах? Вот у меня к примеру были ситуации, когда он херил все файлы, даже без всяких стресс-тестов — в одном случае сервер по ошибке ребутнули из консоли амазона (хотя с хранилищем на тот момент уже несколько часов подряд никто не работал, файлы все-равно повредились), в другом я просто отмонтировал директорию (успешно) и сразу после этого ребутнул сервер командой reboot (тоже ошибок не выдало), примонтировал после ребута — а файлы повредились. Бывали случаи, когда более часа не мог размонтировать после заливки одного 3-х мегабайтного файла — umount.s3ql просто висел часа 1.5 и молча ждал чего-то.
Это мне так не везло, и у всех все надежно работает под большими нагрузками и со всякими нештатными ситуациями, или s3ql никто не юзает в реальной жизни, даже Селектел?
Это мне так не везло, и у всех все надежно работает под большими нагрузками и со всякими нештатными ситуациями, или s3ql никто не юзает в реальной жизни, даже Селектел?
Все хорошо. Одного не понимаю — где и как авторизоваться?
В приведенных примерах утилита спрашивает при запуске. Можно сохранить пароль в файл, выставить минимальный доступ к нему (типа 600) и указывать его с ключом
--authfile.Мне показалось из текста, что это пароль на шифрование, а я спрашиваю про аутентификацию на сервисе.
Или я неправ? Шифровать-то мне не надо, duplicity и сама прекрасно справится, а вот выбор контейнера/авторизация…
Или я неправ? Шифровать-то мне не надо, duplicity и сама прекрасно справится, а вот выбор контейнера/авторизация…
Имя пользователя и имя конейнера — в урле. Пароль — в
Для автоматического монтирования нужно использовать скрипт, который использует authfile.
Про шифрование ничего не знаю.
--authfile или утилита переспросит.Для автоматического монтирования нужно использовать скрипт, который использует authfile.
Про шифрование ничего не знаю.
спасибо
Я соврал.
authfile — это INI-подобный файл, структура описана здесь.
Написал скрипт, который использует сабж для резервных копий: #comment_6172351. Вроде даже работает. :)
authfile — это INI-подобный файл, структура описана здесь.
Написал скрипт, который использует сабж для резервных копий: #comment_6172351. Вроде даже работает. :)
Я уже в глубинах. Даже с суппортом пообщаться успел :-)
например, если обозвать файло authinfo2 и заложить его в ~/.s3ql/ то опции не нужны. и монтируется все одной командой, без скриптов.
а для бэкапа намереваюсь использовать duplicity. Это прикольней, кмк.
Но вот сейчас лазил там, и обнаружил, что duplicity умеет коннектиться к S3 «искаропки». и залип… это выходит, что после некоторого напилинга можно обойтись без s3ql?
потому как это очень просто написано «демонтирует», а в жизни это операция влегкую небыстрая, я даже на тесте это уже понял.
например, если обозвать файло authinfo2 и заложить его в ~/.s3ql/ то опции не нужны. и монтируется все одной командой, без скриптов.
а для бэкапа намереваюсь использовать duplicity. Это прикольней, кмк.
Но вот сейчас лазил там, и обнаружил, что duplicity умеет коннектиться к S3 «искаропки». и залип… это выходит, что после некоторого напилинга можно обойтись без s3ql?
потому как это очень просто написано «демонтирует», а в жизни это операция влегкую небыстрая, я даже на тесте это уже понял.
Круто.
Жаль, Duplicity принудительно всё архивирует. У меня созданием и ротацией архивов занимается хостинговая платформа, и архивировать архивы — это как-то черезжопно. :(
Да и S3, как я понимаю, тоже не позволяет просматривать и скачивать содержимое через вэб-интерфейс.
Так что шило на мыло.
Жаль, Duplicity принудительно всё архивирует. У меня созданием и ротацией архивов занимается хостинговая платформа, и архивировать архивы — это как-то черезжопно. :(
Да и S3, как я понимаю, тоже не позволяет просматривать и скачивать содержимое через вэб-интерфейс.
Так что шило на мыло.
Если архивные файлы у вас подготавливает другая система, то можете просто воспользоваться специальной утилитой supload. Будет не сложно настроить загрузку архивив в Хранилище и причем обеспечить их автоматическое удаление по времени (если нужно). Подробнее можно почитать в статье про настройку резервного копирования настройку резервного копирования (Использование supload).
Наша Хранилище поддерживает API S3, единственное, само ПО бывает жестко заточено под амазон и перенастроить бывает не совсем просто.
Наша Хранилище поддерживает API S3, единственное, само ПО бывает жестко заточено под амазон и перенастроить бывает не совсем просто.
Я пробовал supload. Проблема с ним в том, что он не умеет удалять в хранилище файлы, отсутствующие локально.
Средство создания бэкапов проводит ротацию — бэкапы старше одной недели удаляются (на всякий случай сохраняется по одному бэкапу за год, сезон, месяц, неделю).
Если пользоваться supload, в хранилище будут оставаться все бэкапы за все дни. В результате расход дискового пространства и денег становится неоправданно большим. За те же деньги я мог бы взять второй VPS в том же ДЦ, что и первый, и делать бэкапы на него непосредственно rsync'ом.
Средство создания бэкапов проводит ротацию — бэкапы старше одной недели удаляются (на всякий случай сохраняется по одному бэкапу за год, сезон, месяц, неделю).
Если пользоваться supload, в хранилище будут оставаться все бэкапы за все дни. В результате расход дискового пространства и денег становится неоправданно большим. За те же деньги я мог бы взять второй VPS в том же ДЦ, что и первый, и делать бэкапы на него непосредственно rsync'ом.
supload позволяет сказать Хранилищу сколько по времени нужно хранить, как раз это позволит обеспечить удаление файлов при их ротации. Об этот как раз написано в той статье, внизу.
Средство создания бэкапов само определяет, какие файлы удалить, а какие оставить.
Я не представляю, как сказать утилите — этот храни неделю, этот храни год, не вручную же.
Понимаете, идеальным в своей простоте решением задачи является rsync. Существует немало облачных хранилищ, которые поддерживают его напрямую. Может, и вы начнете его поддерживать?
Я не представляю, как сказать утилите — этот храни неделю, этот храни год, не вручную же.
Понимаете, идеальным в своей простоте решением задачи является rsync. Существует немало облачных хранилищ, которые поддерживают его напрямую. Может, и вы начнете его поддерживать?
Конечно, научить supload задавать разное время требует усилий по написанию более-менее сложного скрипта для этого. В общем, если хочется, то можно сделать так.
Не спорю, rsync очень удобен сам по себе. Но реализовать его протокол для Хранилища пока не представляется возможным.
Кстати, было бы интересно посмотреть на список облачных хранилищ с поддержкой rsync, которыми реально пользуются.
Не спорю, rsync очень удобен сам по себе. Но реализовать его протокол для Хранилища пока не представляется возможным.
Кстати, было бы интересно посмотреть на список облачных хранилищ с поддержкой rsync, которыми реально пользуются.
так и s3ql тоже создает свой контейнер, который выглядит бессмысленным в веб-панели.
а duplicity умеет не зипать, насколько я помню. не шифровать точно может :-)
и у duplicity бонусы в том, что она здорово уменьшает трафик за счет разумного диффа. Во всяком случае, раньше, когда у меня бэкапы делались без облаков, просто с одного сервера на другой, и трафик тарифицировался — она выглядела лучше других. К тому же, там у нее внутри версионность поддерживается. И если что — ее архив можно просто разобрать, там внутри gpg да тар с гзипом. или бзипом. но ничего такого особенного.
а duplicity умеет не зипать, насколько я помню. не шифровать точно может :-)
и у duplicity бонусы в том, что она здорово уменьшает трафик за счет разумного диффа. Во всяком случае, раньше, когда у меня бэкапы делались без облаков, просто с одного сервера на другой, и трафик тарифицировался — она выглядела лучше других. К тому же, там у нее внутри версионность поддерживается. И если что — ее архив можно просто разобрать, там внутри gpg да тар с гзипом. или бзипом. но ничего такого особенного.
Заливаю бэкапы с лондонского Linode на сабж при помощи
Средняя скорость закачки каждого файла колеблется вокруг значения 2.2 MB/s.
rsync --progress.Средняя скорость закачки каждого файла колеблется вокруг значения 2.2 MB/s.
Теоретически можно получить большую скорость если распараллелить rsync — www.rath.org/s3ql-docs/tips.html#improving-copy-performance
Написал скрипт, который монтирует сабж, копирует туда бэкапы и демонтирует.
github.com/lolmaus/selectel-s3ql-backup
Если кто решит воспользоваться, пожалуйста, прежде чем полагаться на него, убедитесь, что он работает исправно.
github.com/lolmaus/selectel-s3ql-backup
Если кто решит воспользоваться, пожалуйста, прежде чем полагаться на него, убедитесь, что он работает исправно.
За две недели использования сабжа второй раз контейнер недоступен с ошибкой «Transport endpoint is not connected». Бэкапы, соответственно, не сохраняются.
В общем, штука крайне ненадежная.
Перехожу на DigitalOcean.com, там за 150 руб./мес. дают VPS с 20GB SSD, и первые два месяца бесплатно. Буду бэкапиться напрямую rsync'ом.
В общем, штука крайне ненадежная.
Перехожу на DigitalOcean.com, там за 150 руб./мес. дают VPS с 20GB SSD, и первые два месяца бесплатно. Буду бэкапиться напрямую rsync'ом.
Sign up to leave a comment.
s3ql — файловая система на базе облачного хранилища