~ 300 GB VMDK-Dateilaufwerk, das als VMFS auf Ubuntu Server 14.04 LTS formatiert wurde, konnte nicht erfolgreich kopiert werden

Okay, ich werde versuchen, meine Situation gründlich zu erklären. Mein gegenwärtiger Zustand ist dies. Ich habe eine 500-GB-Festplatte, die sich früher in einem Server befand - sie hosten VMs - und war eines von zwei Laufwerken in RAID 1. Ich gehe davon aus, dass beide Laufwerke an diesem Punkt identisch sind, aber ich habe das andere Laufwerk, aus welchem ​​Grund auch immer Dieser funktioniert nicht oder ich muss ihn benutzen.

Dieses Laufwerk ist an eine kleine Linux-Box über Onboard-SATA (es ist ein IntelITIT-MiniITX-Mobo-Server) angeschlossen, auf der Ubuntu Server 14.04 LTS ausgeführt wird, der eigens für diesen Zweck eigens installiert wurde. Ich habe installiert vmfs-tools, um Zugriff zu gewähren vmfs-fuse, die ich als solches für die Bereitstellung des Laufwerks verwende:

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

Dies funktioniert erfolgreich als Read-Only-Mount (beachten Sie, dass / dev / sdb mein Startlaufwerk ist, sie sind vertauscht, da ich die SATA-Ports gemischt habe). Meine fdisk lautet wie folgt:

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 

Ich kann den Inhalt des Ordners mit meiner problematischen Datei erfolgreich lesen 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 

Als ich natürlich testen wollte, ob ich die Dateien richtig lesen kann, in der Hoffnung, dass der Inhalt nicht beschädigt wurde, versuchte ich tailFolgendes 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. 

Also das funktioniert gut, es ist wahrscheinlich kein Laufwerksproblem. In jedem Fall wollte ich die SMART-Daten überprüfen. Das Laufwerk funktionierte einwandfrei, bevor ich sie zum Upgrade zog. Ich habe installiert smartmontoolsund dann:

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. 

Für mich sieht das nach einem ziemlich einfachen SMART-Bericht für ein altes Laufwerk aus, insbesondere für ein Laufwerk mit 32638 Stunden (1352 Tagen!) Einschaltzeit. Ich habe den Bericht bereits auf dem anderen Laufwerk (Raid-Paar) ausgeführt und die Ergebnisse waren ziemlich ähnlich, wenn ich mich richtig erinnere.

Das betreffende Laufwerk enthält etwa 8 VMs, von denen ich kein Problem hatte, das Laufwerk zu entfernen. Dafür habe ich einen einfachen cpBefehl für ein anderes Laufwerk verwendet und das war es. Dieses Ziellaufwerk, auf dem auch das Betriebssystem läuft, hat etwa 700 GB frei. Das Problem begann, sobald cpdie größte VMDK-Datei (mit großem Abstand) von allen Dateien erreicht wurde. Die meisten VMDKs waren etwa 25 bis 30 GB groß, während das problematische etwa 300 GB betrug. Die große VMDK wurde ursprünglich als eine dicke VMDK erstellt. Hier ist was 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 

Alles, was ich über den Input/output errorDeal gelesen habe, bedeutete, dass die Festplatte ausfiel. Aber ich hatte auf beiden Laufwerken das gleiche Problem, und der SMART-Test schien in Ordnung zu sein. Ich denke, es könnte etwas anderes sein. Die Dateigröße kann auch ein Faktor sein.

Also entschied ich mich, es zu versuchen rsync, da eine bitweise Kopie besser zu mir passen könnte. Dieser ist ein bisschen unbekannter. Zunächst schien es, rsyncals ob das gut funktionierte, ich konnte ls -aldas Zielverzeichnis und die temporäre Dateigröße stetig vergrößern. Sobald die Zieldatei jedoch die entsprechende Größe erreicht hat, werden die Meldungen Input/output errorwie zuvor rsyncangezeigt. Anschließend wird der Vorgang erneut gestartet, wobei die gerade übertragene Datei (oder zumindest teilweise) gelöscht wird. Sprechen Sie über frustrierend. So sieht diese Ausgabe aus:

Etwas mehr als zur Hälfte und geht gut:

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 

Und nach Fertigstellung:

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 

Wirklich, am Ende bin ich nach einigen Dateien, die sich in der VMDK befinden. Wenn es eine Möglichkeit gibt, die VMDK direkt einzubinden, würde ich das gerne wissen, aber alles, was ich online zu diesem Thema gesehen habe, funktioniert nicht, zumeist, weil ich ein VMFS-Volume habe, anstatt etwas direkteres wie EXT4 . Ich dachte, es könnte ein paar Problemumgehungen geben, aber ich bin mir nicht ganz sicher

Ich dachte, ich könnte versuchen, die beiden Laufwerke wieder im Server zu platzieren, meine ESXi-VMs neu zu erstellen und die Daten auf diese Weise abzurufen? Nee. Der Server, auf dem sie sich befanden, ist ein Dell Poweredge 1950 mit einem SAS 6i / R-RAID-Controller, auf dem bereits ein anderes Array installiert ist. Ich konnte die Laufwerke nicht wieder einlegen und sie in ESXi laden, wenn ich wollte, ohne sie zumindest zu formatieren.

Hier wende ich mich an SuperUser. Irgendwelche Vorschläge, was ich tun könnte? Irgendeine Art alternativer Kopierhilfe? Eine Möglichkeit, die VMDK bereitzustellen, wenn das Laufwerk als VMFS formatiert ist? Ein Fix für meine Eingabe- / Ausgabefehler? Vielleicht sogar die VMDK manuell zerreißen? Ich hatte nur eine einzige Partition auf dem Image selbst. Es ist also ziemlich leicht zu erraten, wo die angegebene virtuelle EXT4-Partition beginnen würde, aber ich weiß nicht, wie die VMDK-Dateien strukturiert sind.

Ich schätze Ihre Zeit beim Lesen!