cnc-club.ru

Тема не совсем по ЧПУ, а скорее всего по общему администрированию Linux систем. Но не что прекрасное нам не чуждо ! Тем более на станках есть вибрации => повышенный износ оборудования.

Итак, начнем. Как бы то не было странно, но все необходимое наверняка уже есть в системе и ничего дополнительного устанавливать не придется.

Способ первый - dd

Простой бэкап целого диска (не важно винчестер это или flash или cd) можно сделать при помощи не менее простой команды dd. Эта команда может быть очень полезна, если в качестве винчетсера на станке используется usb flash или CF с CF-IDE переходником. Для создания образа нам нужно знать адрес устройства.
Винчетсеры и flash обычно называются /dev/sd[буква]цифра. Буква - номер физического устройства - винчестер 1, винчестер 2 и т.д. Цифра - номер логического раздела.
Пользоваться dd проще простого dd if=<откуда> of=<куда>, if - input file, of - output file. of может быть любым, другим устройством, файлом на диске, местом в памяти.

Минусы

• если файловая система содержит ошибки, после восстановления из такого бэкапа вы получите ФС с теми же ошибками
• для распаковки такого бэкапа потребуется раздел объемом не меньше исходного, вне зависимости от количества занятого места на разделе
• копируется все содержимое раздела, будь то ваши файлы или просто свободное место, что сказывается на скорости
• необходимость дополнительных манипуляций при распаковке на раздел большего размера
• нестандартный сопособ получения информации о процессе работы утилиты

Плюсы

• Можно быстро делать копию рабочей flash или сделать ее дубликат.

Например: сделает копию диска sdb1 на диск sdc1.

Главное не перепутать if и of !

Способ второй - rsync

rsync это очень мощный инструмент для синхронизации файлов и директорий. В простом случае он сравнивает источник и целевой директорий и дополняет целевой директорий изменившимися файлами. Поэтому rsync очень удобен для создания автоматических бэкапов.
Для того, чтобы сделать полный бэкап системы нужно сделать копию всех файлов, кроме временных каталогов и системных ресурсов (/dev /proc ...)
Делаем бэкап системы: Как сделать эту процедуру автоматической, для этого ее нужно добавить в планировщик задач cron. Для этого сохраняем код выше в отдельный файл, скажем /etc/backup.sh и выполняем sudo cron -e. Откроется редактор cron, в этом редакторе каждая строчка это отдельное задание из расписания.

Пример: m - это минуты (30 минут)
h - часы (17)
dom = day of month (1-31 стоит любой)
mon = month (1-12 стоит любой)
dow = день недели (0-7 0 и 7 воскресенье, стоит пятница)

Таким образом скрипт будет срабатывать каждую пятницу в 17:30.

Так же при помощи rsync и cp можно настроить ротацию backup с сохранением нескольких последних копий. При этом копии будут занимать совсем мало места, т.к. мы будем хранить только изменившиеся файлы.
Не вдаваясь в подробности ротация вместе с самим бэкапом делается так:

Спопоб третий

Предлагайте

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

для распаковки такого бэкапа потребуется раздел объемом не меньше исходного, вне зависимости от количества занятого места на разделе

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

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

нестандартный сопособ получения информации о процессе работы утилиты
(скопир с сайта убунты.ру)

Nick писал(а):of может быть любым, другим устройством, файлом на диске

т.е. dd if=/dev/sda1 of=/home/pkm/backup тоже пойдет?

пс: сегодня внезапно слетела карта CF на 8 гиг, работала через переходник CF-SATA. просто исчезли все разделы. ставлю на нее же заново все, и сделаю бэкап

Да, должно сработать, причем вроде файл будет типа iso и его можно будет при надобности замаунтить как диск .

Что-то на сетевой диск не выходит скопировать...

$ sudo dd if=/dev/sda1 of=smb://pkm@192.168.0.199/d$/backup/pkm.iso

dd: opening `smb://pkm@192.168.0.199/d$/backup/pkm.iso': No such file or directory

Создавал файл - не помогает... а в справке dd о сетевых дисках не упоминается. Без расширения .iso - аналогично

Скорее всего надо сначала сетевой диск примонтировать. Пока диск не примонтирован он не файл.
Т.е. либо через наутилус подсоединяешься к smb и потом ищешь этот диск в /media либо через моунтишь его сам куда хочешь
mount -t cifs //ntserver/download -o username=vivek,password=myPassword /home/nkp/ntserver

примонтировал, вроде пошлО )
думаю, займет чертову тучу времени по сети... о, а я сейчас на переносной диск попробую!

Сеть - быстрая штука, я как-то 30 гигов за по часа слил, у нас в сети был ретрекер...
Скорее чтение с флешки будет медленнее. Какая у нее скорость чтения?

Скорость флешки по встроенному тесту убунты 30МБ/с, время доступа 0.5 мс.
Но средняя скорость бэкапа составила всего 1.4 МБ/с, в результате 7.1ГБ часа полтора заняло...
Архив монтируется, но содержимое не показывает...
Еще rsync нужно попробовать

Что dd, что rsync - не показывают оставшееся время, вот ерунда

По dd есть вот такая штука:
Если послать работающему процессу `dd' сигнал USR1, он напечатает на
стандартный поток ошибок статистику ввода/вывода и продолжит
копирование.
$ dd if=/dev/zero of=/dev/null& pid=$!
$ kill -USR1 $pid; sleep 1; kill $pid
18335302+0 входных записей
18335302+0 выходных записей
9387674624 байта (9.4 GB) скопировано, 34.6279 секунды, 271 MB/s

Это вывод из dd --help , также есть еще вот это: http://www.commandlinefu.com/commands/v ... statistics

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

Думаю в эту тему будет праильнее перехать.
Задача.
Перенести с виртуальной машины систему на реальную.
Ни разу так не делал, попытка увенчалась обломом.
ХДД виртуального диска чуть-чуть больше чем реального. Однако раздел виртуального с системой точно меньше реального.
Что я делал.
sda - виртуальный винт, там только раздел /
sdb - реальный
1) с LiveCD
слил бэкап с MBR
sudo dd if=/dev/sda of=/dev/sdb bs=512 count=1
sudo cp -ax /media/(UUID_sda) /media/(UUID_sdb)
загружаюсь, ругается на UUID, и горит приглашение (initramfs). Что тут делать?
2) загружаю виртуалку, убираю из fstab UUID, прописываю там явно /dev/sda1
делаю update-grub
делаю dd if=/dev/sda of=/dev/sdb bs=8M (правильно ли делать bs=8M для записи на CF-карту, скорость просто раз в 30 выше??)

Не работает точно таким же способом.
Как правильно?

Для простоты считаем, что на обоих машинах будет 1 файловая система, без отдельных /var, /usr и т.п. /dev/sda - диск для целевой машины, /dev/sdb - диск исходной машины (виртуальной). В принципе можно и наоборот, но так будет меньше путаницы и на одной перезагрузке можно сэкономить.
1. Загрузить Linux с CD или флешки (live-cd например).
2. Подмонтировать раздел / от виртуальной машины в какой-нибудь каталог, например /src.
3. На диске для реальной машины создаём раздел для / (путь будет sda1) и, если нужно раздел свопа (sda2).
4. Создаём файловые системы:
mke2fs -t ext4 /dev/sda1
mkswap /dev/sda2
5. Монтируем /dev/sda1 в какой-нибудь каталог, например в /dst
6. Переносим систему, только нужно не убить служебный каталог lost+found, его проще сохранить, чем потом заново создавать:
mv /dst/lost+found /dst/lost+found.save
cp -avx /src/. /dst/
rmdir /dst/lost+found
mv /dst/lost+found.save /dst/lost+found
7. Дальше нам понадобятся UUID разделов, добыть их можно командой
blkid
результат запишите куда-нибудь.
8. на целевой системе надо поправить fstab, правим /dst/etc/fstab, вписываем там вместо старого новый UUID. Можно поступить вообще жоско и вместо UUID=...... написать /dev/sda1 (это название раздела с системой, когда будет загружаться целевая машина без лишних дисков).
9. Теперь надо на целевой диск установить загрузчик. Если у вас целевой диск получился не как я советовал выше, а /dev/sdb, то вам надо отключить исходный диск и снова загрузится с CD.
Выполняем команду
chroot /dst
и оказываемся как-бы в целевой системе. Если конфиг загрузчика у вас правильный (не забудьте сменить там UUID или можно так-же просто указать имя раздела), то достаточно будет просто выполнить команду
grub-install --recheck /dev/sda

Всё, теперь целевая система сама в состоянии загружаться.

P.S. Писал по памяти, вроде ничего не упустил.

спасибо, попробую завтра, отпишусь

до пп 9 все сработало. Потом воспользоался http://ubuntologia.ru/grub2-recovery
поскольку косяки были из-за не примонтированных /proc и /dev

А, точно, про них забыл. Их надо было подмонтировать с опцией bind.
Я в основном с редхатами и клонами имею дело, а там при загрузке с rescue-cd оно само это делает.

upd: Ну или можно обойтись без chroot, но тогда устанавливать загрузчик придётся в рукопашную:
1. запускаем grub без параметров и аргументов
2. Говорим ему где находится FS, содержащая его файлы (/boot):
root (hd0,0)
указан нулевой раздел на нулевом диске, т.е. /dev/sda1 (нумерация с нуля).
3. Говорим ему куда поставить загрузчик:
setup (hd0)
т.е. в MBR /dev/sda.
Всё, теперь с этого диска как мимнимум загрузится grub, а из него можно загрузить всё, что угодно. Если в /boot лежал правильный grub.conf, то загрузится то, что там сказано.

UAVpilot писал(а):только нужно не убить служебный каталог lost+found

А для чего он нужен вообще?

ЗЫ наверное в таком образе действительно стоит поменять все UUID на /dev/sda ведь на компе от станка не должно быть дополнительных винчестеров. А копировать образ станет гораздо легче .

Nick писал(а):

UAVpilot писал(а):только нужно не убить служебный каталог lost+found

А для чего он нужен вообще?

Он нужен при "ремонте" файловой системы (fsck). Например если запортится файл какого-нибудь каталога, то в FS останется кучка безымянных файлов. fsck их найдёт (про таблице инодов), даст им имя по номеру первого используемого ими инода и поместит в этот каталог. Так-же туда будут помещены найденные "обрывки" файлов и т.п.
Cоздать его с помощью mkdir нельзя - он должен помещаться в строго определённых инодах в FS.

UAVpilot писал(а):Cоздать его с помощью mkdir нельзя - он должен помещаться в строго определённых инодах в FS.

А если ты сделаешь ему cp разве он в теже иноды запишется? Тем более на новом носителе потеряных файлов не будет, точнее они будут не нужны....

А никто ему cp не делает. Если внимательно посмотреть на команды, то на целевой ФС он прячется за угол, чтоб его не переписал тот, что копируется с исходной. А потом скопированный удаляется, а родной вынимается из нычки.
А на новой ФС потерянные файлы обязательно будут, потом, когда некорректно выключишь.
К тому-же некоторые вложенные и рекурсивные ошибки fsck не сможет исправить, если иноды и блоки, зарезервированные под /lost+found окажутся занятыми какими-то данными или даже свободным местом.