Восстановление или перенос сервера freebsd

Восстановление или перенос сервера Freebsd

Хочу рассказать, как относительно быстро восстановить работоспособность умершего freebsd сервера, либо перенести полностью сервер с одной машины на другую. Для этого нам понадобится программа для архивации fsbackup и live-cd с freebsd. Сразу предупреждаю, что это не how to, нужен некоторый уровень знания и понимания ОС freebsd.

Первым делом сделаем сам архив. Для архивирования любых данных я использую простую и удобную программу fsbackup. Подробнее о ней можно узнать тут http://www.opennet.

ru/dev/fsbackup/ В конфиге комментарии на русском языке, так что с настройкой проблем быть не должно. Архив можно хранить локально, на удаленном ftp, либо заливать через ssh на другой сервер. Поддерживается шифрование, создание инкрементных бэкапов.

Программа живет в портах /usr/ports/sysutils/fsbackup Для бэкапа системы я использую следующий конфиг:

$cfg_backup_name = “srv12_domain_local”; $cfg_cache_dir = “/usr/local/fsbackup/cache”; $prog_md5sum = “md5sum -b”; $prog_tar = “/usr/bin/tar”; $prog_ssh = “/usr/bin/ssh”; $prog_rm = “/bin/rm”; $prog_gzip = “/usr/bin/gzip”; $prog_pgp = “gpg”; $cfg_checksum = “timesize”; $cfg_backup_style = “backup”; $cfg_increment_level = 7; $cfg_save_old_backup = 1; $cfg_type = “remote_ftp”; $cfg_remote_ftp_mode = 0; $cfg_remote_password = “password”; $cfg_local_path = “/mnt/backup/srv12/system”; $cfg_time_limit = 0; $cfg_size_limit = 0; $cfg_maximum_archive_size = 0; $cfg_root_path = “/”; $cfg_verbose = 2; $cfg_stopdir_prune=0; 1; __DATA__ #Архивируем весь сервер с корня / #Указываем папки исключения, которые бэкапить не нужно !/dev !/mail !/mnt !/usr/ports !/var/db/portsnap !/usr/local/fsbackup/cache !/web/squidcache !/web/mysql !/usr/src

!/usr/local/www/data-dist/netams

Я архивирую весь сервер, за исключением некоторых папок, которые указаны отдельно.

Архив мы получили, теперь нужно подготовить сервер, на который будет осуществляться перенос. Для этого на исходном сервере необходимо открыть /etc/fstab запомнить существующие разделы и затем создать такие же разделы на другом сервере.

/dev/ar0s1b none swap sw 0 0 /dev/ar0s1a / ufs rw 1 1 /dev/ar0s1f /mail ufs rw 2 2 /dev/ar0s1d /tmp ufs rw 2 2 /dev/ar0s1e /usr ufs rw 2 2 /dev/ar0s1g /var ufs rw 2 2 /dev/ar0s1h /web ufs rw,suiddir,noatime 2 2 /dev/acd0 /cdrom cd9660 ro,noauto 0 0

Размер разделов может не совпадать, достаточно просто наличие таких же разделов. Я разбиваю диск с помощью установочного диска freebsd и custom install на нем: разбиваю непосредственно диск и ставлю загрузчик freebsd.

После того, как создали разделы, копируем наш бэкап куда-нибудь, чтобы потом можно было его забрать на второй сервер, загрузившись с live-cd. Можно скопировать на ftp, можно на флешку, можно просто в виндовую шару положить и потом ее подмонтировать. Вместе с архивом нужно скопировать скрипт fsrestore.

sh, который лежит в /usr/local/fsbackup/scripts. Этот скрипт будет выполнять непосредственно восстановление системы.

Теперь берем live-cd, я использую Frenzy, и грузимся с него. В принципе, пользоваться можно чем угодно, любым live-cd с freebsd, но мне нравится именно Frenzy. После загрузки имеем полноценную систему, которая автоматически подмонтировала созданные нами ранее разделы. Подмонтированы они в режиме чтения, так что сначала отмонтируем их.

umount /dev/ad4s1a

и так далее со всеми разделами.

Затем в папке /mnt создадим папки с именами разделов нашей системы, которую мы переносим. В моем случае это папки /mnt/tmp, /mnt/usr, /mnt/var, /mnt/web, /mnt/mail.

Далее монтируем разделы в только что созданные папки, при этом раздел / монтируем в /mnt

mount /dev/ad4s1a /mnt mount /dev/ad4s1f /mnt/mail mount /dev/ad4s1d /mnt/tmp mount /dev/ad4s1e /mnt/usr mount /dev/ad4s1g /mnt/var mount /dev/ad4s1h /mnt/web

Теперь нужно подмонтировать флешку с архивом:

mount_ntfs /dev/da0s1 /mnt/backup

Не забываем заменить /dev/da0s1 на то устройство, каким является флешка у вас.

Можно вместо флешки подмонтировать виндовую шару. Перед монтированием шары необходимо не забыть настроить сеть либо через sysinstall, либо сразу c помощью ifconfig:

ifconfig eth0 192.168.0.15 netmask 255.255.255.0 ifconfig eth0 up

Монтируем шару:

mount_smbfs -I 192.168.0.2 -E koi8-r:cp866 //user@comp/shara /mnt/backup

user – имя пользователя шары, comp – имя компьютера в сети shara – имя шары

Итак, у нас есть бэкап, есть подмонтированные разделы будущей системы. Теперь можно начать восстановление. Для этого редактируем скрипт fsrestore.sh. В нем нужно изменить только две строчки:

# Директория где находится бэкап. backup_path=”/mnt/backup” # Корневая директория куда будут помещены данные восстановленные из бэкапа. restore_path=”/mnt”

После этого запускаем скрипт и ждем завершения. Лучше бэкап скопировать куда-нибудь локально, и затем запускать восстановление. Так будет быстрее и надежнее. После завершения восстановления, проверяем файлы. В данный момент в папке /mnt должна находиться копия нашего сервера.

Сейчас нужно внести некоторые изменения в конфигурацию. Первым делом обязательно нужно отредактировать файл /mnt/etc/fstab так как имена дисков в разных серверах могут быть разными.

На исходном сервере у меня было зеркало ar0 , перенес же я на одиночный хард ad4. Соответственно, меняем в fstab ar0 на ad4. Тут же можно поменять сетевые и прочие настройки в rc.conf но это уже не критично.

Все остальное можно будет изменить загрузившись в системе. Если же не отредактировать fstab, то, скорее всего, мы не загрузимся.

После восстановления перезагружаем компьютер, вытаскиваем live-cd, логинимся в систему. Осталось выполнить последнее действие. Вместе с непосредственно архивом fsbackup создает файлик с правами доступа и владельцами на все файлы и папки в архиве. Файл этот имеет расширение .

dir Во время восстановления скрипт не отработал и не расставил нужные права, так как путь восстановления был не в / а в /mnt/, поэтому пути в файле не совпадали с путем восстановления. Так что теперь нам нужно вручную исполнить этот файл, чтобы полностью восстановить все права и владельцев.

Для этого ставим ему права на исполнение и запускаем. После его исполнения мы имеем точную копию системы.

Все описанное собственноручно проверялось много раз. Очень просто и удобный способ восстановления или переноса freebsd сервера.

Помогла статья? Есть возможность отблагодарить автора

Дополнительные материалы по Freebsd

Рекомендую полезные материалы по Freebsd:

Описание установки Freebsd 11 на одиночный диск, либо на софтовый raid1, сделанный средствами zfs, которые поддерживает стандартный установщик.Базовая настройка Freebsd, которую можно выполнить после установки сервера общего назначения. Представлены некоторые рекомендации по повышению удобства пользования и безопасности.Описание и нюансы обновления системы Freebsd с помощью утилиты freebsd-update. Показано пошагово на конкретном примере обновления.Настройка Freebsd шлюза для обеспечения выхода в интернет. Используется ipfw и ядерный нат, dnsmasq в качестве dhcp и dns сервера. Мониторинг сетевой активности с помощью iftop.Настройка максимально быстрого web сервера на базе Freebsd и nginx + php-fpm. Существенный прирост производительности по сравнению с классическим apache.

Источник: https://serveradmin.ru/vosstanovlenie-ili-perenos-servera-freebsd-za-30-minut/

Особенности восстановления/переноса FreeBSD на хост с другой аппаратной конфигурацией

Для профессионалов, знающих Linux, BSD системы понятны «по аналогии», за исключением некоторых особенностей. Об особенностях и пойдет разговор.

Да, есть великолепное руководство по FreeBSD на оффициальном сайте, и даже на русском языке оно тоже есть, но момент о котором пойдет речь описывается далеко не на первой странице, а если «падает» критически важный сервер, к которому подходил последний раз лет -цать назад (или вообще никогда), и его нужно срочно поднять на другом хосте с неаналогичной конфигурацией, то искать можно долго. И в то же время, это те основы, без изучения которых дальше идти нельзя. Итак, практическая задача: перенос FreeBSD на другой хост (контроллеры могут различаться: IDE/Raid ISCI/VMware ESX/Citrix Xen). Всем известно, что если жесткий диск с WinXP перенести на другой компьютер (аналогичный), то скорее всего (~99%), система загрузится. Если контроллеры HDD несовместимы, то можно получить знакомый BSOD. Схожая ситуация с Linux — там будет черная паника ядра.) С BSD есть пара интересных вариантов. Мой первый топик будет коротким, поэтому я буду рассматривать только один мой «плохой» вариант. Перенос «в лоб» дает ошибку загрузки корневого каталога. Из-за чего это произошло? а) Система именования дисков изменилась (Саму нотацию именования можно посмотреть в любом руководстве по BSD)

б) Система нумерации дисков тоже изменилась (В BSD есть разница, в какой порт IDE/Sata вы подключили жесткий диск, и это не зависит от расстановки в загрузчике BIOS)

(Все же, коротко о необходимой дополнительной информации: «Основной раздел» — Slice — участок. Сокращение s1 — первый участок. Разделом в BSD называется сегмент внутри участка («Windows основного раздела»).

Раздел (аналог логическому диску в Windows) имеет специальный файл, именование которого образуется от имени участка-slice добавлением буквы (a,b,c,d,e,f …). Swap традиционно имеет букву “b”. На диск — участок не более 4, разделов не более 8.

Логическая структура – Disk Label Описание структуры диска: /etc/fstab Стандартная структура каталога – имя раздела, точка монтирования / root (root directory, not a root folder) / swap (2(3)xRAM) / tmp /var

/ usr)

Алгоритм решения: 1)Загрузиться с загрузочного диска, поддерживающего файловую систему FreeBSD. Подойдет frenzy. Во время загрузки мы внимательно смотрим как именуется обнаруженный старый диск на нашем новом железе.

Помним, что найденный диск наша загрузочная система может смонтировать в режиме «только чтение», поэтому проверяем это командой mount, и если это так, то перемонтируем (отмонтируем и монтируем заново) в обычном режиме.

Далее находим файл fstab (отвечает за монтирование дисков) и вручную (vi, mc) правим на нужный. Лично в моем случае строки типа ad4s1a (… ad4s1f) (корневой каталог /) и все остальные нужно было переименовать в da0s1a, (… da0s1fa), что соответствует участку 1 нулевого SCSI диска.

В другом случае именование может измениться. Сохраняемся. Перезагружаемся. Должно загрузится.

Далее вас ждет проверка работоспособности сети, ПО, возможное пересобирание портов и т.п., но это вопрос следующий…

Источник: https://habr.com/post/140720/

FreeBSD Резервное копирование системы

Поговорим о создании резервной копии нашей системы на FreeBSD тобишь бэкапа.

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

Итак, ближе к делу

В этой статье я приведу один из множества вариантов организации бэкапа сервера на FreeBSD. Полностью: от создания, до восстановления.

Создание бэкапа FreeBSD

Для создания резервной копии нашей системы воспользуемся утилитой dump.

Важное замечание, необходимо чтобы в сервере помимо жесткого диска с системой был вставлен другой физический жесткий диск с примонтированной папкой, куда мы и будем делать бэкап. (Далее в примере это папка BACKUPDUMP)

Создадим файл со скриптом на shell в папке /usr/local/etc, который будет делать наш бэкап. И назовем его script_backup.sh

#!/bin/sh

# Создаем файл info.txt в котором будет храниться дата создания бэкапа
date > /BACKUPDUMP/info.txt
# и состояние разделов на момент создания.
df -h >> /BACKUPDUMP/info.txt
# Записываем каждый раздел в отдельный файл бэкапа
dump -0 -L -f – /var > /BACKUPDUMP/var.img dump -0 -L -f – /usr > /BACKUPDUMP/usr.img dump -0 -L -f – / > /BACKUPDUMP/root.img

#!/bin/sh # Создаем файл info.txt в котором будет храниться дата создания бэкапа date > /BACKUPDUMP/info.txt # и состояние разделов на момент создания. df -h >> /BACKUPDUMP/info.txt # Записываем каждый раздел в отдельный файл бэкапа dump -0 -L -f – /var > /BACKUPDUMP/var.img dump -0 -L -f – /usr > /BACKUPDUMP/usr.img dump -0 -L -f – / > /BACKUPDUMP/root.img

Разберем утилиту dump

-0 — делается полный бэкап раздела

-L — дамп снимается с «живой» файловой системы. В корне раздела создается директория .snap куда и делается снимок текущего состояния файловой системы, с помощью которого снимается дамп.

-f — Писать дамп в файл

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

chmod 755 script_backup.sh

И положим его в cron, добавив такую строчку

0 5 10,20,30 * * root /usr/local/etc/script_backup.sh

В 5 утра примерно каждые 10 дней наш скрипт будет выполняться, обновляя файл info.txt и перезаписывая в файлы бэкапы разделов.

Восстановление из бэкапа

Не менее важная часть, которую стоит отработать, прежде чем придется столкнуться с ней в реальности.

Для успешного восстановления воспользуемся Frenzy — это Live-CD на базе ОС FreeBSD.

Скачиваем ее здесь и записываем образ на диск или флешку.

Грузимся с диска или с флешки и начинаем восстановление:

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

(ВАЖНО: не удалите случайно данные на жестком диске с файлами бэкапа, лучше на всякий случай на время установки отсоедините его)

Если же вы просто хотите вернуть систему к предыдущему состоянию, то соответственно разделы все уже на месте, поэтому просто восстанавливаем систему из бэкапа:

Итак, мы уже имеем разделы на жестком диске и загрузили Frenzy

По умолчанию он уже примонтировал все разделы (команда «df -h» покажет вам все разделы ), поэтому делаем так:

Здесь приведен пример восстановления раздела usr, имена разделов будут отличаться от ваших.

Размонтируем раздел

umount /mnt/ad8s1d.ufs

Отформатируем его

newfs /dev/ad8s1d

Примонтируем обратно

mount /dev/ad8s1d /mnt/ad8s1d.ufs

Зайдем в него

cd /mnt/ad8s1d.ufs

И собственно восстановим данные из файла бэкапа

restore -r -f /mnt/ad6s2d.ufs/usr.img

Всю процедуру проделываем для каждого раздела. Будьте внимательны названия разделов у вас могут иметь совершенно другие названия. Можно ориентироваться по размеру.

После проделанных действий перезагружаемся с уже восстановленного жесткого диска с системой.

Источник: http://ITfound.ru/99-freebsd-dump-backup-script.html

Бэкап/перенос FreeBSD (dump/restore)

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

Но недавно, после длительной инсталяции Directadmin’а и допиливания хостинг-сервера под свои нужды, по непонятым причинам побились системные файлы, в часноcти /etc/master.passwd.

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

Для себя поставил задачу сделать бэкап(snapshot) системы в целом, дабы в день X развернуть ее за несколько минут. А вот бэкапы конфигов и нужных даных — как и ранее переодически хранить на отдельном сервере.

Далее опишу свою методику создания и розволрачивания бэкапа FreeBSD.

На отдельном сервере(192.168.1.1) поднимаю NFS-сервер. На сервере, который нужно забекапить

# df -h Filesystem Size Used Avail Capacity Mounted on /dev/ada0s1a 991M 813M 98M 89% / devfs 1.0k 1.0k 0B 100% /dev /dev/ada0s1e 991M 28k 912M 0% /tmp /dev/ada0s1f 886G 5.8G 810G 1% /usr /dev/ada0s1d 9.7G 348M 8.6G 4% /var procfs 4.0k 4.0k 0B 100% /proc

монтирую NFS-шару в /mnt/backup, куда буду складывать архив бэкапа (настройка NFS-клиента описана тут)
mount_nfs 192.168.1.1:/mnt/backup /mnt/backup

Смотрим, что получилось

Создание бэкапа в файл

Поначалу, я вооружился man’ом по комманде dump, и смело выполнял бэкап в файл следующим способом:

dump -0 -auLf – / | gzip -q > /backups/root.dump.gz dump -0 -auLf – /usr | gzip -q > /backups/usr.dump.gz dump -0 -auLf – /var | gzip -q > /backups/var.dump.gz

Применяемые опции:
-L – дамп снимается с «живой» файловой системы, т.е. она смонтирована в режиме запись/чтение (при ее использовании создается снимок в директории .snap, корневого раздела, который будет удален по завершению работы dump);
-f – писать в файл (по умолчанию вывод направлен на стример).

НО ЭТО НЕ РАБОТАЕТ!

Бэкап создается, но при попытке развернуть его, получил ошибку вида:

unknown tape header type 16777216 abort[yn]n Checksum error 65411300137, inode 0 file resync restore, skipped 69168 blocks expected next file 70660, got 0 … partial block read: 20253 should be 32764 End-of-tape encpuntered Mount tape volume 2 Enter “none” if there are no more tapes otherwise enter tape name (default: /mnt/backup/var.dump.gz2) … ругань на cannot create hard link … bad entry: incomplete operation name: /sbin/adjkerntz parent name ./sbin sibling name: ./sbin/zpool entry type: LEAF inode number: 70660 flags: NEW abort?[yn]

Данную проблему можно обойти если делать snapshot самому, а затем дампить с него. Делаем snapshot корня в файл /.snap/2014010700

mount -u -o snapshot /.snap/2014010700 /

Привязываем созданный снапшот к устройству /dev/md1 (номер зависит от праметра -u)

mdconfig -a -t vnode -f /.snap/2014010700 -u 1

Делаем простой дамп

dump -0 -a -f root_ad4s1a.img /dev/md1

Если нужен запакованный дамп

dump -0 -a -f – /dev/md1 | gzip -9 > root_ad4s1a.img.gz

Если нужен запакованный дамп со сбросом на ftp

dump -0 -a -f – /dev/md1 | gzip -9 – | ftp -u ftp://login:password@host/root.dump.gz –

Т.е. получается, что делается дамп со снапшота, затем переадется через пайп (|) на архивацию gzip, после чего отправляем по ftp. Синтаксис отправки по ftp [протокол]://[логин]:[пароль]@[сервер]/[путь/][файл_дампа].

Отключаем снапшот mdconfig -d -u 1

При этом, мы не блокировали никаких операций на HDD, не перемонтировали в RO и получили рабочий дамп, в чем сейчас и убедимся.

Написал небольшой php-скрипт, который автоматизирует процес бекапа

Перенос системы с винта на винт

Если нужно не бэкапить, а перенести с hdd на другой hdd, то:

1) Создаем временные каталоги для монтирования нового hdd

mkdir /tmp/root /tmp/var /tmp/usr

Монтируем слайсы нового hdd

mount /dev/ad4s1a /tmp/root mount /dev/ad4s1e /tmp/var mount /dev/ad4s1d /tmp/usr

Выполняем dump для каждого старого раздела, направив вывод в соответствующий новый, следующим образом:

( dump -0Lf – / ) | ( cd /tmp/root ; restore -rf – ) ( dump -0Lf – /var ) | ( cd /tmp/var ; restore -rf – ) ( dump -0Lf – /usr ) | ( cd /tmp/usr ; restore -rf – )

Также следует отметить, что дамп живой системы (параметр L) невозможен при включенном журналировании. Если при выполнении дампа у вас возникла ошибка

то необходимо загрузиться в Single Mode и выполнить отключение journaled soft-updates

tunefs -J disable /dev/adaxxx tunefs -n disable /dev/adaxxx tunefs -j disable /dev/adaxxx

Источник: https://www.skleroznik.in.ua/2015/10/11/bekapperenos-freebsd-dumprestore/

Backup в Freebsd | Записки на память

Итак, ближе к делу

Создание бэкапа FreeBSD

Для создания резервной копии нашей системы воспользуемся утилитой dump.

Важное замечание, необходимо чтобы в сервере помимо жесткого диска с системой был вставлен другой физический жесткий диск с примонтированной папкой, куда мы и будем делать бэкап. (Далее в примере это папка BACKUPDUMP)

Создадим файл со скриптом на shell в папке /usr/local/etc, который будет делать наш бэкап. И назовем его script_backup.sh

#!/bin/sh # Создаем файл info.txt в котором будет храниться дата создания бэкапа date > /BACKUPDUMP/info.txt # и состояние разделов на момент создания. df -h >> /BACKUPDUMP/info.txt # Записываем каждый раздел в отдельный файл бэкапа dump -0 -L -f – /var > /BACKUPDUMP/var.img dump -0 -L -f – /usr > /BACKUPDUMP/usr.img dump -0 -L -f – / > /BACKUPDUMP/root.img

Разберем утилиту dump

-0 – делается полный бэкап раздела

-L – дамп снимается с “живой” файловой системы. В корне раздела создается директория .snap куда и делается снимок текущего состояния файловой системы, с помощью которого снимается дамп.

-f – Писать дамп в файл

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

chmod 755 script_backup.sh

И положим его в cron, добавив такую строчку

0 5 10,20,30 * * root /usr/local/etc/script_backup.sh

Можно выполнять dump напрямую из копируемой системы, для этого необходимо использовать ключ -L – в таком случае, утилита dump создаст snapshot (“слепок“) системы, и уже с него будет делать копию. Это необходимо, что бы корректно скопировались такие файлы как базы данных.

Внимание: если в файловой системе используется journaled soft-updates – то dump тут не поможет. Как вариант – использовать tar. Возможно – во FreeBSD 10.* эту проблему исправят.

В данном примере будет произведено копирование с выключенной ОС и файловой системы.

Загружаемся с любого LiveCD, например – Frenzy. Для удобства работы – настроим сеть:

# ifconfig em0 inet 77.120.***.29 netmask 255.255.255.0
# route add default 77.120.***.1

Настроим NS, в файл /etc/resolv.conf добавим строку:

nameserver 8.8.8.8

Теперь, надо создать пользоваля, под которым мы будем подключаться по SSH, с помощью команды adduser и запустить сам сервер SSH:

# service sshd onestart

Найдем раздел с FreeBSD, который необходимо копировать:

# ls /dev | grep da da0 da0p1 da0p2

da0p3

В данном примере, весь диск разбит на один корневой раздел, его мы и будем копировать:

# file -s /dev/da0p2
/dev/da0p2: Unix Fast File system [v2] (little-endian) last mounted on /, last written at Mon Dec 17 09:45:20 2012, clean flag 1, readonly flag 0, number of blocks 7340016, number of data blocks 7223927, number of cylinder groups 39, block size 32768, fragment size 4096, average file size 16384, average number of files in dir 64, pending blocks to free 0, pending inodes to free 0, system-wide uuid 0, minimum percentage of free blocks 8, TIME optimization

Если бы на диске присутствовали другие разделы, например раздел /tmp, то определить их можно так (пример с другой машины):

# file -s /dev/da0p4
/dev/da0p4: Unix Fast File system [v2] (little-endian) last mounted on /tmp

Теперь, можно выполнить само копирование.

Что бы не копировать лишнее – установим флаги nodump на каталоги и файлы, которые не требуются в резервной копии:

# chflags nodump /var/log/

Просмотреть флаги можно командой ls с ключём -o:

# ls -Glo total 66176 drwxrwxr-x 2 root operator – 512 Aug 2 18:16 .snap -r——– 1 root wheel schg,sunlnk,nodump 33554432 Aug 2 18:16 .

sujournal drwxr-xr-x 2 root wheel – 512 Jan 3 2012 account drwxr-xr-x 4 root wheel – 512 Jan 3 2012 at drwxr-x— 2 root audit – 512 Jan 3 2012 audit drwxr-x— 2 root wheel – 512 Jan 6 03:02 backups drwxr-x— 2 root wheel – 512 Jan 3 2012 cache drwxr-x— 2 root wheel – 512 Jan 3 2012 crash drwxr-x— 3 root wheel – 512 Jan 3 2012 cron drwxr-xr-x 14 root wheel – 512 Jan 6 09:08 db dr-xr-xr-x 2 root wheel schg 512 Jan 3 2012 empty drwxrwxr-x 2 root games – 512 Jan 3 2012 games drwx—— 2 root wheel – 512 Jan 3 2012 heimdal

drwxr-xr-x 6 root wheel nodump 2048 Jan 6 03:29 log

Будут использоваться такие ключи:

0 — максимальный уровень сохранения информации при дампе;
a – не проверять наличие места на диске;
f – сохраняет дамп в файл.

Запускаем:

# dump -0af – /dev/da0p2 | ftp -u ftp://user:[email protected]/user.kioko.dump –

DUMP: Date of this level 0 dump: Mon Dec 17 12:52:22 2012 DUMP: Date of last level 0 dump: the epoch DUMP: Dumping /dev/da0p2 to standard output DUMP: mapping (Pass I) [regular files] Trying 77.120.***.145… Connected to backup.dc.server.com. 220———- Welcome to Pure-FTPd [privsep] ———- 220-You are user number 3 of 500 allowed.

220-Local time is now 13:52. Server port: 21. 220-This is a private system – No anonymous login 220 You will be disconnected after 15 minutes of inactivity.

331 User user OK. Password required 230-OK. Current restricted directory is / 230 2093188 Kbytes used (0%) – authorized: 230686720 Kb Remote system type is UNIX.

Using binary mode to transfer files. 200 TYPE is now 8-bit binary remote: user.kioko.dump 500 Unknown command 227 Entering Passive Mode (77,120,112,145,197,214) 150 Accepted data connection DUMP: mapping (Pass II) [directories] DUMP: estimated 5522617 tape blocks.

DUMP: dumping (Pass III) [directories] DUMP: dumping (Pass IV) [regular files] DUMP: 11.46% done, finished in 0:38 at Mon Dec 17 13:36:10 2012 DUMP: 26.86% done, finished in 0:27 at Mon Dec 17 13:29:47 2012 DUMP: 41.36% done, finished in 0:21 at Mon Dec 17 13:28:48 2012 DUMP: 57.

57% done, finished in 0:14 at Mon Dec 17 13:27:17 2012 DUMP: 72.81% done, finished in 0:09 at Mon Dec 17 13:26:53 2012 DUMP: 86.39% done, finished in 0:04 at Mon Dec 17 13:27:16 2012 DUMP: 100.

00% done, finished in 0:00 at Mon Dec 17 13:27:33 2012 DUMP: DUMP: 5523577 tape blocks DUMP: finished in 2102 seconds, throughput 2627 KBytes/sec DUMP: DUMP IS DONE 226-7616758 Kbytes used (3%) – authorized: 230686720 Kb 226-File successfully transferred 226 2390.344 seconds (measured here), 2.26 Mbytes per second

5656135680 bytes sent in 35:12 (2.55 MB/s)

Или, для примера – выполнение dump с архивацией bzip и загрузкой по FTP:

# dump -0Laf – /dev/da0p3 | gzip -9 | ftp -u ftp://user:[email protected]/user.akira_root.dump – Trying 77.120.***.145:21 … Connected to backup.dc.server.com. 220———- Welcome to Pure-FTPd [privsep] ———- 220-You are user number 10 of 500 allowed. 220-Local time is now 10:27. Server port: 21.

220-This is a private system – No anonymous login 220 You will be disconnected after 15 minutes of inactivity.

… DUMP: Date of this level 0 dump: Sun Jan 6 09:27:29 2013 DUMP: Date of last level 0 dump: the epoch DUMP: Dumping snapshot of /dev/da0p3 (/) to standard output 150 Accepted data connection DUMP: mapping (Pass I) [regular files] DUMP: mapping (Pass II) [directories] DUMP: estimated 204012 tape blocks.

DUMP: dumping (Pass III) [directories] DUMP: dumping (Pass IV) [regular files] … 226-7703473 Kbytes used (6%) – authorized: 125829120 Kb 226-File successfully transferred 226 319.935 seconds (measured here), 271.04 Kbytes per second

88796593 bytes sent in 05:19 (271.04 KiB/s)

Вот и сам файл дампа:

# lftp user:[email protected] lftp [email protected]:~> ls

-rw-r–r– 1 65534 nogroup 88796593 Jan 6 10:32 user.akira_root.dump

Дамп выполнен. Проверим:

# ftp [email protected] Trying 77.120.***.137… Connected to backup.dc.server.com. … 150 Accepted data connection … -rw-r–r– 1 65534 nogroup 5656135680 Dec 17 14:32 user.kioko.dump …

ftp>

Копия раздела готова.

Что бы проверить целосность файла дампа и/или просмотреть его содержимое – можно вспользоваться утилитой restore с ключём -t, например:

# restore -t -f user.kioko.dump Dump date: Mon Dec 17 14:52:22 2012 Dumped from: the epoch 2 . 3 ./.snap 1184000 ./dev 1231360 ./bin 1231361 ./bin/cat 1231362 ./bin/chflags … 1326229 ./var/tmp/sess_a804d5f5bc0d2d331489fad183c255f5 1326232 .

/var/tmp/sess_5abd13a40fa846c494b2c04f856a430d 1326101 ./var/yp 1326102 ./var/yp/Makefile.dist 1326103 ./var/yp/Makefile 1564442 ./var/lib 1615541 ./var/lib/dbus 5 ./sys 6 ./.profile 7 ./.cshrc 8 ./COPYRIGHT 2806 ./home 9 .

/entropy

4 ./.sujournal

Русский man по утилите dump можно найти, например, у Лиссяры тут>>>.

Размещено в рубрике: HOWTO’s, Utilities, Разное with 0 Comments

Восстановление из бэкапа

Не менее важная часть, которую стоит отработать, прежде чем придется столкнуться с ней в реальности.

Для успешного восстановления воспользуемся Frenzy – это Live-CD на базе ОС FreeBSD.

Скачиваем ее здесь и записываем образ на диск или флешку.

Грузимся с диска или с флешки и начинаем восстановление:

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

Итак, мы уже имеем разделы на жестком диске и загрузили Frenzy

По умолчанию он уже примонтировал все разделы (команда “df -h” покажет вам все разделы ), поэтому делаем так:

Здесь приведен пример восстановления раздела usr, имена разделов будут отличаться от ваших.

Размонтируем раздел

Отформатируем его

Примонтируем обратно

mount /dev/ad8s1d /mnt/ad8s1d.ufs

Зайдем в него

И собственно восстановим данные из файла бэкапа

restore -r -f /mnt/ad6s2d.ufs/usr.img

После проделанных действий перезагружаемся с уже восстановленного жесткого диска с системой.

Backup с помощью утилиты

C её помощью можно буквально одной командой сделать резервую копию всего диска, причем, не обязательно, чтобы новый винт был такой-же емкости. Утилита автоматически создаст разделы на новом диске пропорциально изменив разделы.

Правда такой подход не всегда удобен, если вам, к примеру, необходимо увеличить только один раздел.

В этом случае придется использовать, ранее упомянутые dump|restore, предварительно создав неоходимые слайсы и партиции на новом винте.

Я отвлекся от главного… для начала необходимо установить утилиту из портов:

# cd /usr/ports/sysutils/clonehdd/ # make install

Синтаксис утилиты имеет следующий, интуитивно понятный вид:

# clonehdd -src=device -dst=device -swap=size [-safe] [-freespace=size] [-fstab=device] [-force]

Команда df выведет нам список партиций работающей системы, примерно так:

# df Filesystem 1K-blocks Used Avail Capacity Mounted on /dev/ad8s1a 507630 53002 414018 11% / devfs 1 1 0 100% /dev /dev/ad8s1d 1012974 163980 767958 18% /tmp /dev/ad8s1e 5077038 1961624 2709252 42% /usr /dev/ad8s1f 67056618 188536 61503554 0% /var

Как видите, в моем случае диском-источником будет ad8, т.е. парметр -src=ad8.

Имя нового диска, на который будет делаться копия системы, можно узнать, выполнив команду dmesg и посмотрев каким устройством он стал (в моём примере /dev/ad9)

Параметр -swap=size задает размер файла-подкачки swap на новом HDD (указывается в Mb).

Параметр -safe можно не указывать. Он нужен для безопасного переноса данных. Т.е. при резервном копировании, образ партиции сначала создается на том же разделе, откуда происходит копирование и только после этого идет запись на новый жесткий диск в соответствующий раздел.

Таким образом, на копируемом разделе должно быть минимум 50% свободного пространства. Если параметр не указан, clonehdd сам анализирует своболное место на разделе и если его не хватает, то копирование производится «на лету», без создания образа.

На разделах, где сос вободным местом всё в порядке, копирование производится в безопасном режиме.

Вот как выглядел процесс создания клона диска FreeBSD у меня:

# clonehdd -src=ad8 -dst=ad9 -swap=4096

Clone parameters: Source partition: /dev/ad8 Dest partition: /dev/ad9 Swap size: 4096 MB Safe dumping: Disabled Free space on DST: 100 MB Fstab device name: ad8 — [OK] Found devices for clone procedure [OK] DST partitions are not in use — Source partition /usr size: 29748MB, used: 3654MB /var size: 49586MB, used: 2357MB / size: 495MB, used: 239MB /tmp size: 11167MB, used: MB /home size: 366958MB, used: 93178MB Total: 457957 MB, used: 99430 MB — [OK] Device ad9 has enough free space DATA ON DEVICE ad9 WILL BE DESTROYED NOW! Continue? [yes/no]: yes Wait 10 seconds before start: 10 9 8 7 6 5 4 3 2 1 [OK] Device /dev/ad9 made clean [OK] New slice created — Destination device partitions: SWAP size: 4096 MB / size 511 MB /tmp size 11530 MB /var size 51198 MB /usr size 30715 MB /home size 378887 MB — [INF] Last partition were increased for 2 blocks [OK] Partitions were created successfully — [OK] Partition /tmp was formatted successfully Starting dump/restore procedure… [OK] [OK] Partition /var was formatted successfully Starting dump/restore procedure…

Источник: http://a.skattv.ru/?p=97&lang=ru

Перенос системы FreeBSD с одного сервера на другой

Имеется сервер под FreeBSD-9.2 на котором установлена и работает хостинг панель.
Требуется перенести систему на новое железо.

Основы процедуры описаны в http://www.freebsd.org/doc/en_US.ISO8859-1/books/faq/disks.html#idp67483184 Это: 1. Размечаем диск на новом сервере(сервер2). 2. Монтируем его во временный каталог.

3. Используем dump – restore для переноса файловой системы со старого сервера (сервер1) на новый.

Опишу подробнее последовательность в моем случае и подводные камни с которыми столкнулся.

На сервере2 грузимся с live-cd (live-usb) и размечаем дисковое пространство: Поскольку размер диска на сервере2 ( RAID 5 ) больше 2TB, то используем схему разметки GPT, а поскольку на сервере1 все дисковое пространство было выделено под корневой раздел, согласно рекомендации по установке хостинговой панели, то на сервере2 поступаем аналогично. Сначала определяем, как именуются в системе дисковые устройства(dmesg), в моем случае это da0. Создаем схему разметки GPT

# gpart create -s gpt da0
da0 created

Создаем boot раздел и устанавливаем туда загрузочный код
# gpart add -t freebsd-boot -l gpboot -b 40 -s 512K da0 da0p1 added # gpart bootcode -b /boot/pmbr -p /boot/gptboot -i 1 da0

bootcode written to da0

Создаем корневой раздел, предварительно рассчитав размер

# gpart add -t freebsd-ufs -l gprootfs -b 1M -s 2690G da0
da0p2 added

Остальное под своп
# gpart add -t freebsd-swap -l gpswap da0 da0p3 added # gpart show 34 5860377965 da0 GPT (2.7T) 34 6 – free – (3.0k) 40 1024 1 freebsd-boot (512k) 1064 984 – free – (492k) 2048 5830082560 2 freebsd-ufs (2.7T)

5830084608 30293391 3 freebsd-swap (14G)

Создаем файловую систему

# newfs -U /dev/gpt/gprootfs

Теперь надо смонтировать полученное устройство /dev/da0p2 (или /dev/gpt/gprootfs) в /mnt

# mount /dev/gpt/gprootfs /mnt

Далее задаем ip адрес для интерфейса к которому будем подключаться с сервера1

# ifconfig igb0 192.168.10.2 netmask 255.255.255.0

Теперь нужно запустить sshd чтобы можно было с сервера1 по ssh передать dump на сервер2. Поскольку мы загрузились с live-usb, то файловая система, в т.ч каталог /etc смонтирован в режиме ридонли. Чтобы запустить sshd нужно отредактировать /etc/ssh/sshd_config, задать пароль root и запустить sshd, для этого – каталог tmp доступен для записи.

# mount_unionfs /tmp/etc /etc

– см. man mount_unionfs меняем в /etc/ssh/sshd-config

PermitRootLogin no на yes

и задаем пароль root –
, после чего стартуем sshd:

# /etc/rc.d/sshd onestart

Переходим к серверу1. Чтобы сделать dump требуется чтобы файловая система на старом сервере была с отключенной опцией soft update journalling.

Изменить этот параметр можно с помощью tunefs, но чтобы это сделать требуется чтобы файловая система была либо размонтирована либо была ридонли. У меня не получилось выполнить tunefs на работающей системе и в single user mode.

Поэтому загрузился на сервере1 с live-cd, и выполнил

# gmirror load
# fsck -t ufs -f /dev/mirror/gmos1a

– сначала исправим ошибки если есть, на всякий случай, предварительно подгрузив gmirror, поскольку он работает на сервере1, затем

# tunefs -j disable /dev/mirror/gm0s1a

Проверяем работает ли ssh соединение, пытаясь подключиться к серверу2. Если все в порядке, то выполняем

# dump -C16 -b64 -0aL -f – / | ssh [email protected] “(cd /mnt && restore -rf -)”

Спустя некоторое время создание и развертывание дампа завершится. Теперь нужно внести изменения в конфигурационные файлы на сервере2, содержащие данные о старом железе, – об именах сетевых адаптеров и дисковых разделов. У меня это были следующие файлы:
/etc/fstab /etc/firewall.conf

/etc/rc.d

После этого, включив новый сервер вместо старого, все заработало.

Ссылки:
http://www.freebsd.org/doc/en_US.ISO8859-1/books/faq/disks.html#idp67480624
https://www.freebsd.org/doc/handbook/geom-mirror.html
http://www.wonkity.com/~wblock/docs/html/disksetup.html
http://deathstar.name/ustanovka-freebsd-cherez-ssh-sessiyu

Источник: https://nixadmin.ru/move_freebsd_filesystem

FreeBSD Tips: перенос базы пользователей

С этого поста я начинаю небольшой цикл статей, который можно условно назвать «FreeBSD Tips». Иными словами, некоторые коротенькие вспомогательные статьи, которые могут быть полезны всем (-: Ничего сакрального я вам не расскажу, а вот интересным что-то может быть (-:

Начнём, как указано в названии поста, с переноса пользователей. Различные могут быть ситуации: купили более мощную машинку, создание резервного сервера, роутера и т.п. Как бы там ни было, а пользователей с одной машины необходимо перенести на другую машину. (-:

Для этого нам понадобятся всего 2 файла: /etc/master.passwd и /etc/group.

Кому-то проще перенести их на флэшке, кому-то на дискете, но ситуации бывают разные: нет дисковода, нет физического доступа к серверу, а пользователей перенести надо.

Поэтому просто скопируем данные файлы при помощи очень замечательной и положительной утилиты scp — secure copy.

Более полную и точную информацию можно, конечно же, узнать по man scp (-: Нас же больше интересует, как перенести два файла по сети, через Интернет и т.п. На самом деле, нет ничего проще:

bash-2.05b# scp -P /etc/group user@RemoteIP:/home/user/

Записи «-P » можно опустить, если у Вас используется стандартный 22 порт. А дальше всё просто: файл с локальной машины «/etc/group» скопировать на удалённую машину с адресом «RemoteIP», под учётной записью пользователя «user». Как вы помните или знаете, а может кто-то и не знает, но по умолчанию FreeBSD не пускает root-а по ssh удалённо.

И это правильно! (-: Поэтому обязательно указать пользователя и папку, куда сохранить. Следует заметить, что у пользователя «user» должны быть права на запись в указанную папку. Поэтому, чтоб не гадать и не выдумывать, советую скопировать в домашний каталог пользователя.

Единственное, что следует добавить про копирование, так это то, что удалённая система спросит пароль для пользователя «user». После этого файл уже окажется в домашнем каталоге.

Осталось совсем немного (-: Однако перед этим следует сделать одну _ОЧЕНЬ_ важную вещь: бэкап уже существующих в системе файлов master.passwd и group. Напомню известную поговорку: Системные администраторы делятся на две категории — на тех, кто УЖЕ делает backup-ы, и тех, кто ещё не делает оных (-: Поэтому настоятельно рекомендую сделать копию заменяемых файлов (-:

После этого записываем на новой машине полученные файлы в каталог /etc. Всё, что необходимо сделать — это выполнить команду:

bash-2.05b#pwd_mkdb master.passwd

Вот и всё! (-: Все пользователи со старой машины перенесены на новую, со своими паролями, шеллами и т.п. Безусловно, содержимое домашних каталогов так не перенесётся, так перенесутся только учётные записи пользователей.

Источник: http://www.none.com.ua/freebsd/freebsd-perenos-bazy-polzovatelej/

Перенос FreeBSD сервера с ZFS root файловой системой на новый пул

ZFS — просто замечательная и великолепная ФС.

Имеется у меня один сервер. Стоят там 2 винта старых, на них зеркало ZFS. Устанавливалось всё по умолчанию:

[root@mav ~]# zfs list NAME USED AVAIL REFER MOUNTPOINT zroot 5.89G 28.8G 144K none zroot/ROOT 1.67G 28.8G 144K none zroot/ROOT/default 1.67G 28.8G 1.67G / zroot/tmp 368K 28.8G 368K /tmp zroot/usr 2.76G 28.8G 144K /usr zroot/usr/home 22.5M 28.8G 22.5M /usr/home zroot/usr/ports 2.25G 28.8G 2.25G /usr/ports zroot/usr/src 507M 28.8G 507M /usr/src zroot/var 1.45G 28.8G 1.45G /var zroot/var/crash 148K 28.8G 148K /var/crash zroot/var/log 672K 28.8G 672K /var/log zroot/var/mail 156K 28.8G 156K /var/mail zroot/var/tmp 160K 28.8G 160K /var/tmp

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

Источник: https://www.afabla.ru/perenos-freebsd-servera-s-zfs-root-fajlovoj-sistem/

Перенос FreeBSD с одного жёсткого диска на другой

Данная статья является дополнением и изменением этой, но с некоторыми поправками.

Диск разбиваем через sysintall (а можно и через fdisk). Ниже будет описан способ через sysinstall.

Вначале создадим в /mnt структуру папок, куда будем монтировать разделы.

# mkdir -p /mnt/{root, var, tmp, usr}

Не забываем сделать раздел активным (загрузочным)! Прикол в следующем, если для будущего корневого раздела, поставить точку монтирования отличную от «/» то он не присваивает разделу букву «a», а присвоит букву «d». Нужно проделать такие комбинации — установить при создании раздела точку монтирования «/», затем поменять её клавишей «M».

Disk: ad2 Partition name: ad2s1 Free: 389668226 blocks (190267MB) Part Mount Size Newfs Part Mount Size Newfs —- —– —- —– —- —– —- —– ad2s1a / 512MB UFS Y

Получится так:

Disk: ad2 Partition name: ad2s1 Free: 389668226 blocks (190267MB) Part Mount Size Newfs Part Mount Size Newfs —- —– —- —– —- —– —- —– ad2s1a /mnt/root 512MB UFS Y

Дальше можно смело создавать остальные разделы, только указывая в качестве монтирования путь /mnt/…, иначе оно смонтирует в ваши текущие /usr, /var,.. и нужно будет перегружать сервер через Reset. Когда будут созданы все разделы, нажимаем «W» и записываем все изменения. Если после нажатия W получили ошибки, то скорее всего одна из этих причин:

— неправильно созданы разделы. Решение: выйти из sysinstall’a и создать заново разделы
— возможно часть разделов уже смонтирована где-то
— неправильно указаны точки монтировая

После того как нажали W и выходим, нам предлагаю установить загрузчик. Выбираем Standart Boot Manager (первый пункт) и выбираем наш новый диск. Теперь наш диск имеет загрузчик и может загружаться ОС.

Перенос файловых системы будем делать так (налету, без перезагрузки в single mode — это нам поможет сделать ключ ‘-L’):

#( dump -0 -L -f – / ) | ( cd /mnt/root ; restore -rf – ) #( dump -0 -L -f – /usr ) | ( cd /mnt/usr ; restore -rf – ) #( dump -0 -L -f – /var ) | ( cd /mnt/var ; restore -rf – )

#( dump -0 -L -f – /tmp ) | ( cd /mnt/tmp ; restore -rf – )

После этого, отредактируйте ваш новый fstab: он лежит в /mnt/root/etc/fstab ПРАВИЛЬНО, согласно новым разделам.
В заключение можно ещё пройтись rsync’ом, что бы точно всё перенеслось

Источник: https://skeletor.org.ua/?p=3555