Я же не говорю, что нельзя использвать в проде, я говорю, что можно, но с головой. ;)
Фейсбук пока начал только тестовое использование. Про гугл ничего быстро не нагуглилось.
Восстановление BTRFS это песня. Есть там ошибка, что то вроде «error read chunk root» при которой утилиты восстановления ничего не видят и не восстанавливают. У меня она ломалась несколько раз и каждый раз с этой ошибкой.
История с РО разделом произшла на 3.16-3.17, не исключено, что виновато было включенное сжатие.
С Btrfs нужно быть аккуратным. В ядро 3.16 (или 3.17) прилетел баг, из-за которого система падает в кернел паник при использовании сжатия. Так-же бывает ФС ломается после нескольких хард выключений подряд. Ломается до не восстановимого состояния. Один раз было такое- в нормально работающей системе корень вдруг перемонтировался в РО, после перезагрузки ФС была сломана, восстановлению не подлежала.
Да, все вышесказанное приключилось со мной на Arch Linux, ядра всегда последние. Так что если и использовать в проде BTRFS, то я порекомендовал бы какую нибудь убунту 14.04 (т.к. имеет свежее, но достаточно стабильное ядро), ОБЯЗАТЕЛЬНО иметь бэкап и не забывать, что данная ФС может похерить ваши данные.
З.Ы. В последних ядрах нет изменений BTRFS, кто нибудь знает продолжает ли Oracle разработку, или она заглохла?
Учится чему то новому никто не против. Но создалось впечатление, что ваш коллега не читал стать и быстренько накатал рекламный коммент.
если у нас есть СУБД или другое ПО, которое активно использует собственный кэш на запись, то перед бэкапом его нужно попросить сбросить кэш и заморозить запись на диск, иначе данные-то в снэпшот попадут, но не те
Еще раз: проблема в консистентности данных на диске. Снапшот позволяет получить консистентые данные на уровне блочного устройства или ФС, но это совершенно не значит, что данные будут консистентны на уровне приложения. Что бы они были консистентны приложение нужно оповестить о снятии снапшота (как это делает VSS), что бы оно сбросило кэши и тд. Собственно об этом и статья.
Консистентность для групп ВМ это хорошо, но сначала бы с одной ВМ разобраться.
Если мы друг друга не поняли и у вас эта проблема решена, то будет интересно узнать как.
Проблема не в производительности, проблема в консистентности данных. При вашем подходе запросто может оказаться, что в момент снятия снапшота часть новых данных в БД уже записана на диск, а часть еще в кэше. В итоге мы в бэкапе имеем неконсистентую базу данных. В худшем случае данные могут быть повреждены до полной бесполезности.
Автор поста как раз и говорит о способе сказать приложениям в госте, что нужно сброситьь кэши и приготовится к снятию снапшота, другой способ я описал в первом комментарии.
А чем снимать снапшот дело десятое.
А почему бы не делать суспенд гостя (все содержимое оперативной памяти, значения регистров ЦП и прочее записывается файлом на диск), потом сделать снапшот диска гостя, скопировать образ оперативной памяти и опять включить гостя?
Суспенд занимает около 5-10 сек., столько же на выход из него. В это время естественно гость будет не доступен, но после включения продолжит работать как ни в чем не бывало (только время нужно будет подкорректировать). В данном случае не важно какой гость, т.к. все делается на стороне QEMU. При восстановлении ВМ будет восстановлена в том же состоянии, в котором снимался бэкап.
Музыка тоже несет добро и радость. Представьте что вас на работе будут заставлять в хоре петь, а если плохо поешь, то лишают премии. Понравится такая обязаловка, несущая радость и добро?
Конечно. Как иначе твитнуть «Жителям города ХХХ до испарения осталось 6 минуть. Мира всем»
А по делу в статье же написано, что защищать планируетсясопровождающую инфраструктуру, которая подключена к интернету и представляет определенную ценность (бухгалтерия, документооборот и тд).
Я правильно понял, что с 2009 года могли создаваться невалидные резервные копии при использовании механизма CBT (который использует подавляющее большинство ПО), а заметили это только сейчас?
Никакого централизованного управления тут нет и насколько я понял из комментариев нет даже встроенного планировщика заданий. На серверах конечно можно использовать, но оптимально ли это…
На линуксе достаточно как открытых, так и проприетарных решений. Зачем вам эта система (ну кроме того, что чем больше, тем лучше;) ). К тому же они же написали, что это решение для юзеров, не серверов.
Acronis B&R умеет инсталировать в ОС необходимые дрова при восстановлении и удалять драйвера контроллеров HDD. Symantec насколько помню тоже так умеет.
А если не ворчать, то молодцы, судя по описанию хороший продукт, да еще и бесплатно.
технологических поставщиков, которые предлагают закрытые проприетарные решения, созданные в стенах одной-единственной компании
В новые системы надежно интегрированы технологии IBM и других членов консорциума OpenPOWER, включая GPU-ускоритель NVIDIA
Заменит одну проприетарную технологию на другую?
Или я ошибаюсь и там используется opencl вместо CUDA и можно использовать любую совместимую видеокарту ( AMD например)?
А зачем использовать EFI, если kvm умеет напрямую загружать ядро из хоста. Не требуется загрузчик, легко управлять параметрами загрузки и версией загружаемого ядра. Можно так-же размещать виртуалки на LVM томах без таблицы разделов. В общем все, что описано в статье. Скорей всего даже шаренный реад-онли виртио диск будет работать (не проверял).
sd[a-z] это только sata/(возможно sas) диски. Например диски в KVM называются vd[a-z], в Xen xvd[a-z] (насколько помню). Есть флопики (fd), IDE диски (hd*). Поэтому смотреть листинг /dev не показательно. Лучше воспользоваться /proc/partitions
Поскольку РИТЭГи используют высококонцентрированный плутоний, который рассеялся в атмосфере, произошло значительное повышение радиационного фона по всему миру.
Разве там достаточно радиоактивных материалов, что бы значительно повысить фон во всем мире? И что значить значительно, 2% процентов это значительно или нет? Мне кажется, что при взрыве ат. бомбы в атмосферу выбрасывается не меньше радиоактивной пыли и осколков из активной зоны. А испытаний бомб проводилось очень много.
Использую дома btrfs и на нескольких серверах. Да с дисками виртуалок на жестком диске она работает плохо. Интересно, что на SSD такой проблемы нет и все просто летает. На HDD так-же медленно листятся директории, при большом объеме метаданных. (Винт 4 Тб, метаданных 12 Гб, файлов предположительно около 10 миллионов, lzo сжатие). Выполнение команды ls -l на любой папке тома занимает около секунды -двух). В общем есть куда оптимизировать.
С мнением большинства не соглашусь, btrfs по функционалу достаточно сыра, но стабильна.
duplicity заточен под копирование на удаленные хосты, поддерживает шифрование и облачные хранилища. Мой скрипт это не поддерживает, зато позволяет делать не только полные и дифференциальные файловые бэкапы.
Сейчас посмотрел, очень похоже, что не умеет. rsnapshot сделан на основе rsync. У меня делаются бинарные дифы lvm томов, внутри может быть что угодно, хоть zfs или refs. А rsnapshot по моему просто монтирует lvm том и делает файловую копию.
Не вижу особой надобности в web интерфейсе, все настраивается достаточно легко. Если и делать web интерфейс, то только для сервера управления с возможностью управлять несколькими хостами. Подумаю над этим, возможно сделаю.
Смотрел. Во первых там хоть и написано дифференциальный, но тот rsync скрипт делает инкрементальный бэкап.
Во вторых хотелось универсального решения под свои нужды. Ну а для создания дифов LVM томов я не нашел ни одного решения.
Я говорил о не публичных устройствах: роутеры, свичи, контроллеры умных домов, внутренние сервера компаний, промышленное оборудование (где то на хабре была статья о поисковике уязвимость, там вроде даже измерительное оборудование турбины электростанции нашли) и тд. и тд. Доступ к таким устройствам должен быть как минимум ограничен по IP, а лучше вообще только через VPN. Потому что в куче подобных железок есть бекдоры и тонны багов (таких, как описанные в статье).
Тут правильнее использовать transfer вместо seize, т.к. seize это принудительный захват схемы и возможна ситуация, когда бывший владелец схемы будет считать себя таковым после seize.
Применяется seize только при потери владельца роли и/или невозможности сделать transfer.
Стоит ли написать статью-мануал о своем скрипте бэкапа на python (сейчас похоже только ленивый не пишет свои велосипеды на питоне;))? Умеет делать дифы файловой системы, lvm, email отчеты и прочие плюшки.