Используя dd
может, по моему опыту, вызвать проблемы при восстановлении позже, потому что это считывает данные на блочном уровне от устройства, в то время как файловая система могла бы обновлять блоки в другом порядке. Это приводит к ошибкам файловой системы на восстановленном устройстве. Это также требует, чтобы Вы восстановили к блочному устройству (или иначе смонтировать цикл изображение), таким образом, это не настолько гибко для восстановления.
Всегда существуют проблемы при резервном копировании рабочей системы, которая не поддерживает снимки на уровне ОС, но у меня было меньше проблем с помощью cpio
(и использование tar
было бы то же). Могут быть файлы, которые являются неполными или не в синхронизации друг с другом, но сама базовая файловая система не будет иметь ошибок. Другая альтернатива dd
rsync, если у Вас есть это. Вы делаете вид снимка к другому диску/серверу. С find
и cpio
легко генерировать файл метки времени и сделать второе выполнение с файлами, измененными после метки времени (это работает намного более быстрый, чем orginal, и дайте меньше шанса файлов, являющихся несинхронизированным друг с другом), то же может быть сделано с повторным выполнением rsync
.Neither cpio
ни rsync
соглашение с загрузочным сектором и т.д. необходимо заботиться об этом отдельно. dd
хорошо для этого, поскольку это редко изменяется, в то время как Вы работаете dd
.
Для полной восстановимой установки я делаю дамп из разделения (fdisk -l
или parted -l
), копия загрузочного сектора, список файловой системы вводит на раздел, и cpio
сгенерированный .tar
файлы содержания разделов (все горели на CD/DVD). Восстановление затем подразумевает начальную загрузку от жизни CD, восстановление загрузочного сектора, разделение диска, форматирование разделов и восстановление разделов от tar. (Необходимо смочь сделать это без восстановления загрузочного сектора путем установки личинки после восстановления различного .tar
файлы)
Вы можете увидеть, какие файлы использует процесс, с помощью инструмента lsof
.
$ sudo lsof -p $(pgrep yum) | head -10
lsof: WARNING: can't stat() fuse.gvfsd-fuse file system /run/user/1000/gvfs
Output information may be incomplete.
COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME
yum 5117 root cwd DIR 253,2 4096 8921392 /home/saml/tst/134317
yum 5117 root rtd DIR 253,1 4096 2 /
yum 5117 root txt REG 253,1 11936 556827 /usr/bin/python2.7
yum 5117 root mem REG 253,1 277256 538188 /usr/lib64/libsoftokn3.so
yum 5117 root mem REG 253,1 43808 534669 /usr/lib64/libcrypt-2.17.so
yum 5117 root mem REG 253,1 18168 535410 /usr/lib64/libplds4.so
yum 5117 root mem REG 253,1 247464 534827 /usr/lib64/libnspr4.so
yum 5117 root mem REG 253,1 22272 534919 /usr/lib64/libplc4.so
yum 5117 root mem REG 253,1 1318904 536248 /usr/lib64/libnss3.so
Когда yum
обращается к файлам, таким как база данных RPM:
yum 5117 root mem REG 253,1 1318912 1313544 /var/lib/rpm/__db.003
yum 5117 root mem REG 253,1 90112 1312668 /var/lib/rpm/__db.002
yum 5117 root mem REG 253,1 311296 1312467 /var/lib/rpm/__db.001
Другие процессы, включая rpm
, также не могут получить к нему доступ. YUM также использует базы данных sqlite
, они тоже подвержены блокировке, поэтому другие процессы не могут использовать их, пока YUM.
Вы можете убить его, но вам, вероятно, придется потом произвести некоторую очистку, используя yum-complete-transaction
.
$ sudo yum-complete-transaction
$ yum-complete-transaction --cleanup-only