Архиватор для автоматических бекапов сервера

не путай с ущербными снэпами в lvm, в zfs они по другому работают.

где твои аргументы умник, даже не видя сущность рассуждаешь о ней как о базе данных, жесть просто.

А что будет с нею при ~сотне R/O почти не отличающихся снапшотов?

Если у тебя 100-ня снапшотов и они почти не отличаются то это говорить только о том что fs у тебя на запись используется крайне мало.

А у автора топика между бэкапами успевает набежать под 20Гб. Такие дела.

Да не вопрос - расскажите как они там работают и вместе посмотрим насколько сильна разница

где твои аргументы умник

снапшот != бэкап. Это не аргумент - это факт.

Что до техники работы снапшотов - то ты всегда может рассказать как оно на самом деле, это не больно

аже не видя сущность рассуждаешь о ней как о базе данных

facepalm.jpg большинство fs и являются по сути специализированными БД. Учи матчасть.

архиватор хороший, да. Присоветуй тогда ещё к нему надёжную файловую систему.

Толсто же!

снапшот != бэкап.

да поставь наконец zfs. сделай снапшот, сохрани его в файл, а потом восстанови, и скажи что это не бекап.

facepalm.jpg большинство fs и являются по сути специализированными БД. Учи матчасть

сам учи! ))) Не разу не видел фс а рассуждает о ней, это верх тупизны.

да поставь наконец zfs. сделай снапшот, сохрани его в файл, а потом восстанови, и скажи что это не бекап.

Я возьму tar/dar сохраню директорию в файл и получу бэкап, который прочитаю даже на Винде

Нахрена мне возиться с модулем zfs, разбиением fs, созданием снапшотов, и их восстановлением

Под фряхой или линуксом? Какой транспорт используется?

да он вооще не понимает что это, и пытается об этом расуждать.

разбиением fs

эта фраза говорит от том что zfs вы не трогали ручками

сам учи! )))

Отказываешь ? Ну что ж давай я сделаю это за тебя. Идешь http://ru.wikipedia.org/wiki/ZFS читаешь

ZFS использует модель объектных транзакций на основе механизма копирования при записи.

Именно механизм копирования при записи я на пальцах и описал. Ну а что такое транзакция и какое оно имеет отношение к БД уже погугли сам.

Для решение задачи бэкапа не нужно пробовать zfs. Бэкап нужно уметь выполнять на любой fs. LOL

san под фряхой, тома созданные zvol, раздаются по iscsi

ну так давай выполни на zfs, и скажи что сущность полученная в результате снапшота и записанная в файл, после восстановления не несет в себе копию данных, т.е. не является бекапом. докажи уже.

епт. да транзакции везде используются, это не отличительный признак БД, скажи на улице знакомому привет в ответ услышишь здорово - это тоже будет являться транзакцией

после чего полностью копировать блок в новое место, и скорее всего строить список блоков по всем снапшотов.

вот это и называется ущербная реализация. в zfs для снэпов не надо городить отдельный раздел, используются указатели и ничего никуда не копируется.

на линуксе тоже можно создавать тома zvol и раздаать, но как-то уже привык к фриибсд.

Другое дел готово ли это для прода.

год использую zfs под линуксом, под размещение виртуалок kvm, под виртуалки раздаю не тома zvol, а фс на которой конфиг vm и raw в качестве диска, снапшоты с виртуалками заливаю на резервный сервак, ну и плюс сохраняю резервную копию полного снашота vm в виде файла на бекап-сервер, очень удобно, всем доволен.

еще можешь у King_Carlo поспрашивать по zfs на linux, он наверное уже полгода ее использует тоже под виртуализацию.

Где вы у меня увидели какой то отдельный раздел ?

в zfs для снэпов не надо городить отдельный раздел, используются указатели и ничего никуда не копируется.

Давай и тебе процитирую вики

Блоки данных, содержащие активные (в этот момент) данные, никогда не перезаписываются вместе; напротив, выделяется новый блок, измененные данные записываются в него, а затем метаданные любых блоков, которые на него ссылаются

Создание нового блока и запись измененных данных в него, у меня и описано, и просторечии именно это и называется копированием. Ваш КЭП.

Я уж молчу про саму технику COW у котором слово копирование прямо в названии присутствует

т.е. не является бекапом. докажи уже.

О - я смотрю до тебя начинает доходить LOL.

Бэкапом (резервной копией) является не снапшот, а именно что копия снапшота. Слово копия первично, слово снапшот ничтожно.

Если ты не скопировал снапшот - то совершенно пофигу насколько мгновенно он сделался - ибо он еще не стал бэкапом, а сводить способы получения бэкапов исключительно к снапшотами, это еще нужно об северную стойку сильно головой удариться.

Те же БД снапшотами как правило не бэкапятся, наиболее известного исключение MS SQL у которого демон записи тесно интегрирован с ntfs драйвером и может узнавать когда fs хочет сделать снапшот и выдает разрешение только на блоки вне транзакций.

Я тебя спрашивал в этой теме Вопросы по созданию radi1 о zfs и виртуалках, но ничего путного ты сказать не смог, только повторял zfs это мегакруто. Даже Изя перестал носиться с zfs как с писаной торбой, но пара последователей всегда найдутся.

да поставь наконец zfs. сделай снапшот, сохрани его в файл, а потом восстанови, и скажи что это не бекап

Допустим, сделал снапшот, записал на флешку, сразу после этого злые террористы взорвали датацентр с сервером. Как мне восстановить данные из этого «бэкапа»?

Бэкапом (резервной копией) является не снапшот, а именно что копия снапшота.

да хорош уже крутить и выкручиваться

снапшот можно подключить независимой копией фс и без сохранения в файл

снапшот=копия=бекап

но ничего путного ты сказать не смог

а что говорить, что это работает.

восстановить данные из этого «бэкапа»?

cat backup.mypool | zfs receive -vdF rezerv

где rezerv - любой пул

Ну если так, то да, работает, но ты стучал копытом в грудь, что связка zfs + kvm это чудо чудесное. Объяснить только ничего не смог.

что объяснить? потрать полчаса поставь zfs и пару-тройку виртуалок, и определишься нужно это или нет

Спасибо, за такие советы. Знаешь как это звучит? "Поешь говна, определишь нужно или нет"

а что ты хотел? какие советы? потестить софт влом?

Поешь говна, определишь нужно или нет

некоторым бывает полезно.

а что ты хотел? какие советы? потестить софт влом?

Объяснил бы в чём профит, а то вдруг я не то тестить буду

некоторым бывает полезно.

Ты о себе? Я то не спешу жрать не глядя.

Ты о себе? Я то не спешу жрать не глядя.

нет, о тех кто жрет lvm и думает, что это конфетка.

И при zfs send -i сработает?

О, вот уже в ответ пошли весомые аргументы типа «сам дурак».

у меня к вам пару вопросов:

1. Для чего нужно создавать дополнительный том при снапшоте lvm и что туда пишется?

2. Данные которые меняются в процессе снятия снапшота исходного тома lvm попадут в снапшот?

1. Для чего нужно создавать дополнительный том при снапшоте lvm и что туда пишется?

Для доступа к снапшоту. Туда пишутся новые данные (снапшот не меняется)

2. Данные которые меняются в процессе снятия снапшота исходного тома lvm попадут в снапшот?

Нет. Снапшот на то и снапшот, чтобы быть «фотоснимком» системы на определенный момент времени.

Да снапшоты на уровне блочного устройства, кардинально (в худшую сторону) отличаются от снапшотов на уровне fs.

Но легкие снапшоты zfs при работе с виртуалками роли не играют

дополнительный том
Туда пишутся новые данные

я правильно понял, почему же потом мы с такой легкостью расстаемся с дополнительным томом куда пишутся новые данные?

1. При создания снапшота создаётся только снапшот-том. Никаких других томов не создаётся.
2. В процессе создания снапшот-тома никакие данные не меняются по определению. man COW.

может для начала сам сделаешь man Copy-On-Write

Не совсем, так в этот том копируются блоки которые были изменены в текущем томе, т.е. новые данные идут на свои места, а старое содержимое блоков копируется в этот том для того чтобы остаться доступными снапшоту. Из-за этого лишнего переноса данных проседает скорость работы с диском. При отмене снапшота удаляются старые (уже измененные) блоки.

и lvm и zfs при создании снапшотов используют одинаковый механизм Copy-On-Write, разница лишь в реализации, которая в zfs дает выигрыш

Но мы уходим от той темы: zfs+kvm
В чем фишка?

Я это не скрываю, но снапшоты и kvm не так уж и важны.

Ты в прошлый раз пытался акцентировать не на снапшотах, а на легком управлении размерами вирт. диска и сел в лужу.

разница лишь в реализации, которая в zfs дает выигрыш

разнице не в реализации, а в уровне block vs fs

на блочном уровне приходится один раз читать и два раза писать данные, а на уровне фс только записать данные и подправить указатели на эти блоки.

т.е. консистенции данных у снапшотов zfs и lvm одинаковая, кто-то в прошлый раз говорил об обратном?

Ты так ничего и не понял. Нет такого понятия «консистенции данных у снапшотов»

Ты делаешь снапшот и всё! Консистентность не зависит от механизма снапшота, а от того были ли файлы закрыты и сброшены все буферы.

В случае когда на zfs лежит файл виртуального диска, zfs не может повлиять на его содержимое, т.к. оно управляется изнутри гостя. Делая снапшот, надо предварительно "сказать" гостю, чтобы он привел свою фс в консистентное состояние, после этого можно делать снапшот.

Ты же утверждал, что делая снапшот zfs можно не заботиться о госте и все будет консистентно.