Неудачное копирование ~ 300 ГБ файлового диска VMDK, отформатированного как VMFS, на Ubuntu Server 14.04 LTS

2379
taylorthurlow

Хорошо, я попытаюсь подробно объяснить мою ситуацию, так что терпите меня. Мое нынешнее состояние таково. У меня есть жесткий диск на 500 ГБ, который раньше был на сервере - он размещал виртуальные машины - и был одним из двух дисков в RAID 1. Я предполагаю, что оба диска идентичны на этом этапе, но у меня есть другой диск, если по какой-либо причине этот не работает, или мне нужно его использовать.

Этот диск подключен к небольшой коробке Linux через встроенный SATA (это сервер Intel MiniITX mobo) под управлением Ubuntu Server 14.04 LTS, недавно установленный специально для этой цели. Я установил vmfs-tools, предоставив доступ vmfs-fuse, который я использую как таковой для монтирования диска:

sudo vmfs-fuse /dev/sda1 /mnt/recovery

Это успешно работает как монтируемое только для чтения (обратите внимание, что / dev / sdb - мой загрузочный диск, они меняются местами, потому что я перепутал порты SATA). Мой fdisk выглядит следующим образом:

taylor@nas:~$ sudo fdisk -l /dev/sda  WARNING: GPT (GUID Partition Table) detected on '/dev/sda'! The util fdisk doesn't support GPT. Use GNU Parted.  Disk /dev/sda: 500.1 GB, 500107862016 bytes 255 heads, 63 sectors/track, 60801 cylinders, total 976773168 sectors Units = sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disk identifier: 0x00000000  Device Boot Start End Blocks Id System /dev/sda1 1 975699967 487849983+ ee GPT 

Я могу успешно прочитать содержимое папки, содержащей мой проблемный файл dot-flat.vmdk:

taylor@nas:~$ sudo ls /mnt/recovery/dot dot-flat.vmdk dot.vmdk dot.vmx vmware-1.log vmware-3.log vmware.log dot.nvram dot.vmsd dot.vmxf vmware-2.log vmware-4.log 

Естественно, желая проверить, чтобы убедиться, что я могу читать файлы должным образом, надеясь, что содержимое не были повреждены, я попытался tailING vmware.log:

taylor@nas:~$ sudo tail /mnt/recovery/dot/vmware.log 2014-12-01T09:19:46.553Z| vmx| I120: VMIOP: Exit 2014-12-01T09:19:46.696Z| vmx| I120: Vix: [35957 mainDispatch.c:849]: VMAutomation_LateShutdown() 2014-12-01T09:19:46.696Z| vmx| I120: Vix: [35957 mainDispatch.c:799]: VMAutomationCloseListenerSocket. Closing listener socket.  2014-12-01T09:19:46.715Z| vmx| I120: Flushing VMX VMDB connections 2014-12-01T09:19:46.715Z| vmx| I120: VmdbDbRemoveCnx: Removing Cnx from Db for '/db/connection/#1/' 2014-12-01T09:19:46.715Z| vmx| I120: VmdbCnxDisconnect: Disconnect: closed pipe for pub cnx '/db/connection/#1/' (0) 2014-12-01T09:19:46.721Z| vmx| I120: VMX exit (0). 2014-12-01T09:19:46.721Z| vmx| I120: AIOMGR-S : stat o=1 r=3 w=0 i=0 br=49152 bw=0 2014-12-01T09:19:46.721Z| vmx| I120: OBJLIB-LIB: ObjLib cleanup done. 2014-12-01T09:19:46.721Z| vmx| W110: VMX has left the building: 0. 

Так что это работает нормально, это, вероятно, не проблема с приводом. В любом случае, я хотел проверить SMART-данные. Диск работал нормально, прежде чем я вытащил их, чтобы обновить их. Я установил smartmontoolsи затем:

taylor@nas:~$ sudo smartctl -a /dev/sda smartctl 6.2 2013-07-26 r3841 [x86_64-linux-3.13.0-32-generic] (local build) Copyright (C) 2002-13, Bruce Allen, Christian Franke, www.smartmontools.org  === START OF INFORMATION SECTION === Model Family: Western Digital RE3 Serial ATA Device Model: WDC WD5002ABYS-18B1B0 Serial Number: WD-WCASY4933732 LU WWN Device Id: 5 0014ee 202b597b2 Add. Product Id: DELL� Firmware Version: 02.03B04 User Capacity: 500,107,862,016 bytes [500 GB] Sector Size: 512 bytes logical/physical Rotation Rate: 7200 rpm Device is: In smartctl database [for details use: -P show] ATA Version is: ATA8-ACS (minor revision not indicated) SATA Version is: SATA 2.5, 3.0 Gb/s Local Time is: Sun Dec 7 01:55:02 2014 PST SMART support is: Available - device has SMART capability. SMART support is: Enabled  === START OF READ SMART DATA SECTION === SMART overall-health self-assessment test result: PASSED  General SMART Values: Offline data collection status: (0x84) Offline data collection activity was suspended by an interrupting command from host. Auto Offline Data Collection: Enabled. Self-test execution status: ( 0) The previous self-test routine completed without error or no self-test has ever been run. Total time to complete Offline data collection: ( 9480) seconds. Offline data collection capabilities: (0x7b) SMART execute Offline immediate. Auto Offline data collection on/off support. Suspend Offline collection upon new command. Offline surface scan supported. Self-test supported. Conveyance Self-test supported. Selective Self-test supported. SMART capabilities: (0x0003) Saves SMART data before entering power-saving mode. Supports SMART auto save timer. Error logging capability: (0x01) Error logging supported. General Purpose Logging supported. Short self-test routine recommended polling time: ( 2) minutes. Extended self-test routine recommended polling time: ( 112) minutes. Conveyance self-test routine recommended polling time: ( 5) minutes. SCT capabilities: (0x303f) SCT Status supported. SCT Error Recovery Control supported. SCT Feature Control supported. SCT Data Table supported.  SMART Attributes Data Structure revision number: 16 Vendor Specific SMART Attributes with Thresholds: ID# ATTRIBUTE_NAME FLAG VALUE WORST THRESH TYPE UPDATED WHEN_FAILED RAW_VALUE 1 Raw_Read_Error_Rate 0x002f 200 200 051 Pre-fail Always - 0 3 Spin_Up_Time 0x0027 194 185 021 Pre-fail Always - 3291 4 Start_Stop_Count 0x0032 100 100 000 Old_age Always - 196 5 Reallocated_Sector_Ct 0x0033 200 200 140 Pre-fail Always - 0 7 Seek_Error_Rate 0x002e 200 200 000 Old_age Always - 0 9 Power_On_Hours 0x0032 056 056 000 Old_age Always - 32738 10 Spin_Retry_Count 0x0032 100 100 000 Old_age Always - 0 11 Calibration_Retry_Count 0x0032 100 100 000 Old_age Always - 0 12 Power_Cycle_Count 0x0032 100 100 000 Old_age Always - 106 192 Power-Off_Retract_Count 0x0032 200 200 000 Old_age Always - 99 193 Load_Cycle_Count 0x0032 200 200 000 Old_age Always - 196 194 Temperature_Celsius 0x0022 108 105 000 Old_age Always - 39 196 Reallocated_Event_Count 0x0032 200 200 000 Old_age Always - 0 197 Current_Pending_Sector 0x0032 200 200 000 Old_age Always - 0 198 Offline_Uncorrectable 0x0030 200 200 000 Old_age Offline - 0 199 UDMA_CRC_Error_Count 0x0032 200 200 000 Old_age Always - 0 200 Multi_Zone_Error_Rate 0x0008 200 200 000 Old_age Offline - 0  SMART Error Log Version: 1 No Errors Logged  SMART Self-test log structure revision number 1 Num Test_Description Status Remaining LifeTime(hours) LBA_of_first_error # 1 Short offline Completed without error 00% 32447 -  SMART Selective self-test log data structure revision number 1 SPAN MIN_LBA MAX_LBA CURRENT_TEST_STATUS 1 0 0 Not_testing 2 0 0 Not_testing 3 0 0 Not_testing 4 0 0 Not_testing 5 0 0 Not_testing Selective self-test flags (0x0): After scanning selected spans, do NOT read-scan remainder of disk. If Selective self-test is pending on power-up, resume after 0 minute delay. 

По крайней мере, для меня это выглядит довольно простым SMART-отчетом для старого диска, особенно для одного с 32638 часами (1352 днями!) Времени включения. Я запускал отчет на другом диске (рейд пара), и результаты были примерно одинаковыми, если я правильно помню.

Данный диск содержит около 8 виртуальных машин, все из которых я без проблем извлек из диска. Чтобы сделать это, я использовал простую cpкоманду для другого диска, вот и все. Этот целевой диск, на котором работает ОС, имеет около 700 ГБ свободного места. Начавшаяся проблема cpдостигла самого большого (с огромным отрывом) файла VMDK из всех. Большинство VMDK было около 25-30 ГБ, а проблемный - около 300 ГБ. Большой VMDK изначально был создан как THICK VMDK. Вот что cpделает:

taylor@nas:~$ sudo cp /mnt/recovery/dot/dot-flat.vmdk ~/dot-flat.vmdk cp: error reading ‘/mnt/recovery/dot/dot-flat.vmdk’: Input/output error cp: failed to extend ‘/home/taylor/dot-flat.vmdk’: Input/output error 

Все, что я прочитал об этой Input/output errorсделке, означало, что диск не работает. Но у меня была одна и та же проблема на обоих дисках, и тест SMART выглядел хорошо, поэтому я решил, что это может быть что-то другое. Размер файла также может быть фактором.

Итак, я решил попробовать rsync, так как побитовая копия могла бы подойти мне лучше. Этот немного странный. Сначала мне показалось, что rsyncвсе работает отлично, я ls -alсмог найти целевой каталог и увидел, что размер временного файла постоянно увеличивается. Однако, как только целевой файл достигает нужного размера, он показывает слова, Input/output errorкак прежде, и затем начинает rsyncпроцесс заново, удаляя только что переданный файл (или, по крайней мере, частично). Разговор о разочаровании. Вот как выглядит этот вывод:

Чуть больше, чем на полпути, все в порядке:

taylor@nas:~$ sudo rsync -av --progress /mnt/recovery/dot/dot-flat.vmdk ~/dot-flat.vmdk sending incremental file list dot-flat.vmdk 201,769,451,520 62% 95.50MB/s 0:20:30 

И после завершения:

taylor@nas:~$ sudo rsync -av --progress /mnt/recovery/dot/dot-flat.vmdk ~/dot-flat.vmdk sending incremental file list dot-flat.vmdk 322,122,547,200 100% 81.94MB/s 1:02:29 (xfr#1, to-chk=0/1) rsync: read errors mapping "/mnt/recovery/dot/dot-flat.vmdk": Input/output error (5) WARNING: dot-flat.vmdk failed verification -- update discarded (will try again). dot-flat.vmdk 672,759,808 0% 85.96MB/s 1:00:52 

Действительно, в конце концов, я после некоторых файлов, которые находятся внутри VMDK. Если есть способ монтировать VMDK напрямую, я хотел бы знать, но все, что я видел в сети по этой теме, не работает, в основном потому, что у меня есть том VMFS вместо чего-то более простого, например EXT4., Я подумал, что может быть несколько обходных путей, но я не совсем уверен,

Я подумал, что мог бы попытаться вернуть два диска обратно на сервер, воссоздать мои виртуальные машины ESXi и извлечь данные таким образом? Нету. Сервер, на котором они находились, - это Dell Poweredge 1950 с RAID-контроллером SAS 6i / R, в котором уже есть другой массив. Я не мог вставить диски обратно и загрузить их в ESXi, если бы захотел, по крайней мере, не отформатировав их.

Так что здесь я перехожу к SuperUser. Какие-нибудь предложения относительно того, что я мог сделать? Любая альтернативная утилита копирования? Способ монтировать VMDK, если диск отформатирован как VMFS? Исправление ошибок ввода / вывода? Может быть, даже разорвать VMDK вручную? У меня был только один раздел на самом образе, поэтому было бы довольно легко догадаться, где будет начинаться данный виртуальный раздел EXT4, но я не знаю в первую очередь о том, как структурированы файлы VMDK.

Я ценю ваше время на чтение!

0
Вы можете установить ESXi где-нибудь (не нужно регистрироваться, есть пробный период) и попытаться получить доступ к данным с помощью «официального» драйвера. Daniel B 9 лет назад 0
@DanielB Я пытался спать прошлой ночью и понял, что это все еще вариант. Первоначально я исключил это, потому что у меня нет необходимых мест на сервере для этого, и если я вытаскиваю текущие диски, то мой текущий raid массив ломается. Я собираюсь установить ESXi на другую машину, вероятно, ту же, которую я использовал для этих тестов, и доложу об этом. taylorthurlow 9 лет назад 0
@DanielB Хорошие новости! Это сработало. Мне пришлось запускать ESXi с USB-накопителя, работающего на сервере, потому что блок NAS, который я собирался использовать, не поддерживал аппаратную виртуализацию, а имел только 2 ГБ ОЗУ. В любом случае, я сейчас активно копирую свои данные! taylorthurlow 9 лет назад 0

1 ответ на вопрос

1
taylorthurlow

After a bit of work and a mind-jogging from @DanielB, I realized that I could just set up another ESXi instance on a USB drive on the server, install from scratch, attach the old drive to the SATA port that I used to run my ESXi host drive on, and then recreate the VM that way.

It booted straight up, read my files, and everything went smoothly.

Похожие вопросы