LINUX.ORG.RU
ФорумAdmin

FreeBSD ufs backup


0

1

Добрый день,

Задача: имеется ряд серверов FreeBSD.

Нужно, сделать backup ufs партиций в образы.

При этом: чтобы эти образы были не зависимы от размера изначальной партиции, скажем: чтобы можно было восстановиться на партицию любого размера, лишь-бы влезли данные. -> dd отпадает, clonehdd тоже.

Чтобы было наглядно, псевдографично. - Запустил, выбрал чего куда, нажал старт, ушёл пить чай. -> tar не удобное решение...

clonezilla, partimage имеют beta статус поддержки ufs -> отпадает. Ибо повреждение данных (о чём указанно в документации), мне не надо.

Что делать?

P.S. всё это нужно в виде LiveCD. Имеется Frenzy и slax Live USB. Надо туда, что-либо поставить такое.

★★★★★
Ответ на: комментарий от system-root

Да не удобно всё это... Хотя чёрт знает, может и правда проще написать соотвествующие скрипты...

DALDON ★★★★★
() автор топика
Ответ на: комментарий от DALDON

> The traditional UNIX® backup programs are dump and restore. They operate on the drive as a collection of disk blocks, below the abstractions of files, links and directories that are created by the file systems.

Можно конечно маны почитать, они вроде бекапят по точкам монтирования, но что-то не впечатляет...

DALDON ★★★★★
() автор топика
Ответ на: комментарий от DALDON

ufsdump... Но чёт тоже не очень...

DALDON ★★★★★
() автор топика
Ответ на: комментарий от true_admin

Хочу как в partimage.

Хотя уже читаю man dump. В-целом подходит, главное, чтоб можно было потом восстановить backup на меньший раздел, но который будет обладать достаточным кол-вом места, тут я пока не очень понял, может оно так или нет, вроде может, но описание, что скопировал выше вроде даёт намёк на обратное...

DALDON ★★★★★
() автор топика
Ответ на: комментарий от system-root

Ок.

Как считает Уважаемое комьюнити, на старых FreeBSD like 6.2, можно попробовать сделать большую вкусность в виде опции -L? Выходить в выходной не очень хочется ради создания backup. А так я попробовал бы: создать backup всего чего надо прямо production серверов, развернуть его в вирт. машине - убедиться, что оно работает, и забыть о проблеме.

DALDON ★★★★★
() автор топика
Ответ на: комментарий от iZEN

Да, я понял это из man. Только боюся на production srv делать. Я потестирую конечно сперва. Но всё-же.

Но в-целом вкусно выглядит, отправить среди рабочего дня не спешно: бекап через ssh на удалённый хост, с низким ionice процесса например. :)

DALDON ★★★★★
() автор топика
Ответ на: комментарий от DALDON

снапшоты во фре через задницу работают. Если у тебя хотя бы средняя нагрузка на винты то снапшот положит тачку нафиг. Проверено на 6-х фряхах.

true_admin ★★★★★
()
Ответ на: комментарий от DALDON

http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/ufs/ffs/README.snapshot

Пока читаю. Для моей версии FreeBSD, у меня таки 6.4.

Боязно, машина является корпоративным шлюзом, и если чего не так, мои коки будут на аукционе выставлены...

Думаете лучше не рисковать?

На вирт. машине тесты проходят успешно. dump, restore.

DALDON ★★★★★
() автор топика
Ответ на: комментарий от DALDON

> As is detailed in the operational information below, snapshots are definitely alpha-test code and are NOT yet ready for production use.

Впечатлило...

DALDON ★★★★★
() автор топика
Ответ на: комментарий от DALDON

нереальные тормоза делающие их бесполезными. А так они, по-моему, даже работают, если на диск ничего не писать :).

Справедливости ради на линухах тоже снапшоты лагают ппц если делать multi-level snapshots :)

true_admin ★★★★★
()
Ответ на: комментарий от true_admin

Моя задача просто снять backup при помощи dump. И всё. А если ничего не писать, то смысла в них... Ммм... Что-то возле нуля... У меня на шлюзе не много операций ввода вывода, DNS, да ip forwrad.

Раз уж Вы тут, чуть расскажите как оно работает: сколько должно быть свободного места для успешного создания снапшота? Всё зависит от интенсивности записи? - Или если хочешь снапшот, должен иметь X2 места? То есть: данных на 5гб, значит для снапшота надо иметь как минимум 5гб места?

DALDON ★★★★★
() автор топика
Ответ на: комментарий от DALDON

нет, снапшот изначально имеет размер 0 и растёт по мере изменения данных. Это везде так, это copy on write.

Если на шлюзе нет важных данных которые могут измениться во время дампа то можешь на горячую слить инфу и всё.

true_admin ★★★★★
()
Ответ на: комментарий от DALDON

> Если у тебя хотя бы средняя нагрузка на винты то снапшот положит

тачку нафиг. Проверено на 6-х фряхах.

думается под нагрузкой проблемы в любой ОС есть и все-таки нужно отделять критичные данные (редко модифицируемые) от некритичных (часто модифицируемых). для первых при ограничении нагрузки на запись в момент резервирования и инкрементальных снапшотах (где поддерживается) вполне себе жизнеспособная техника. для второго случая - уже больше задача высокой доступности/дублирования и в этом случае не надо кактус и мышей в одной задаче объединять...)

anonymous
()
Ответ на: комментарий от anonymous

Согласен.

Получилось сделать у меня в режиме on-line всё.

В Понедельник буду разворачиваться. Но на виртуальных машинах полный цикл снятия backup и разворачивание из него прошёл почти успешно. Пришлось только на /var запустить fsck.

Делал так:

dump -aLf - /dev/ad0s1a |gzip -6 |dd of=/mnt/nfs/root.gzip

И так все требуемые разделы в один скрипт завернул.

Восстанавливал так:

gzip -cd /mnt/nfs/root.gzip |( cd /mnt/ad0s1a.ufs ; restore rf - )

На вирт. машинах всё получилось.

DALDON ★★★★★
() автор топика
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.