bei Snapshots ext3 Filesystem Fehler

[cicero]

Hi,

ich hab hier 3 gleiche ESXen mit gesamt 20 Gästen (Windows Server und RedHat/Debian Linux).
Auf einem ESX gibts 2x RHEL: 4.3 und 5.3 jeweils mit Domino und einmal mit Oracle 10g als Server. Ext3 als Filesystem.

Alle Gäste werden (per Veeam) nächtlich gesnaptshotet und wegkopiert.
Jedoch bei diesen beiden RHEL-Servern werden in beim Starten der wegkopierten
Gäste massive Filesystem-Fehler aufgeworfen.

Bin sehr dankbar über Tips, was hier falsch laufen könnte,
oder wie ich mehr Debug-Infos ergattern kann.

Vielleicht bekannte fehler im SCSI-Modul für RHEL3?
Hardware defekt am ESX? .... ?

David

- Filesystem am Quellserver ist vor und nach dem Snapshot konsistent.
- vmware tools sind installiert und laufen
- lspci:

Code: Alles auswählen

00:00.0 Host bridge: Intel Corporation 440BX/ZX/DX - 82443BX/ZX/DX Host bridge (rev 01)
00:01.0 PCI bridge: Intel Corporation 440BX/ZX/DX - 82443BX/ZX/DX AGP bridge (rev 01)
00:07.0 ISA bridge: Intel Corporation 82371AB/EB/MB PIIX4 ISA (rev 08)
00:07.1 IDE interface: Intel Corporation 82371AB/EB/MB PIIX4 IDE (rev 01)
00:07.3 Bridge: Intel Corporation 82371AB/EB/MB PIIX4 ACPI (rev 08)
00:0f.0 VGA compatible controller: VMware Inc [VMware SVGA II] PCI Display Adapter
00:10.0 SCSI storage controller: LSI Logic / Symbios Logic 53c1030 PCI-X Fusion-MPT Dual Ultra320 SCSI (rev 01)
00:11.0 Ethernet controller: VMware Inc VMware High-Speed Virtual NIC [vmxnet] (rev 10)


- lsmod

Code: Alles auswählen

Module                  Size  Used by
nfsd                  213889  17
exportfs               10049  1 nfsd
lockd                  65257  2 nfsd
nfs_acl                 7745  1 nfsd
sunrpc                142757  12 nfsd,lockd,nfs_acl
md5                     8001  1
ipv6                  240225  95
autofs4                22597  0
i2c_dev                14273  0
i2c_core               25921  1 i2c_dev
vmmemctl               15708  0
vmhgfs                 53408  0
dm_mirror              28449  0
dm_mod                 59973  1 dm_mirror
vmxnet                 22144  0
floppy                 58065  0
mptscsih                5569  0
mptsas                 13389  1 mptscsih
mptspi                 13261  5 mptscsih
mptfc                  12617  1 mptscsih
mptscsi                44125  3 mptsas,mptspi,mptfc
mptbase                59617  4 mptsas,mptspi,mptfc,mptscsi
ext3                  118729  3
jbd                    59481  1 ext3
sd_mod                 20545  5
scsi_mod              116941  5 mptsas,mptspi,mptfc,mptscsi,sd_mod


- dmesg (bissl gekürzt

Code: Alles auswählen

Copyright (c) 1999-2005 LSI Logic Corporation
Fusion MPT FC Host driver 3.02.62.01rh
Fusion MPT SPI Host driver 3.02.62.01rh
PCI: Found IRQ 9 for device 0000:00:10.0
mptbase: Initiating ioc0 bringup
ioc0: 53C1030: Capabilities={Initiator}
scsi0 : ioc0: LSI53C1030, FwRev=01032920h, Ports=1, MaxQ=128, IRQ=9
  Vendor: VMware    Model: Virtual disk      Rev: 1.0
  Type:   Direct-Access                      ANSI SCSI revision: 02
SCSI device sda: 524288000 512-byte hdwr sectors (268435 MB)
sda: cache data unavailable
sda: assuming drive cache: write through
SCSI device sda: 524288000 512-byte hdwr sectors (268435 MB)
sda: cache data unavailable
sda: assuming drive cache: write through
 sda: sda1 sda2 sda3 sda4 < sda5 >
Attached scsi disk sda at scsi0, channel 0, id 0, lun 0
Fusion MPT SAS Host driver 3.02.62.01rh
kjournald starting.  Commit interval 5 seconds
EXT3-fs: mounted filesystem with ordered data mode.
SELinux:  Disabled at runtime.
SELinux:  Unregistering netfilter hooks
shpchp: acpi_shpchprm:get_device PCI ROOT HID fail=0x1001
md: Autodetecting RAID arrays.
md: autorun ...
md: ... autorun DONE.
EXT3 FS on sda1, internal journal
device-mapper: 4.5.0-ioctl (2005-10-04) initialised: dm-devel@redhat.com
EXT3 FS on sda5, internal journal
EXT3-fs: mounted filesystem with ordered data mode.
kjournald starting.  Commit interval 5 seconds
EXT3 FS on sda3, internal journal
EXT3-fs: mounted filesystem with ordered data mode.
VMware hgfs: HGFS is disabled in the host
Adding 8385920k swap on /dev/sda2.  Priority:-1 extents:1


[Tschoergez]

Bist Du sicher, dass das Filesystem zu dem Zeitpunkt, zu dem der Snapshot erstellt wird, konsistent ist?
Normalerweise ist das nicht zwingend der Fall, denn beim Snapshot kriegt man nur crash-konsistente Platten (also in etwa so, wie wenn Du bei nem physikalischen Server den Stecker ziehst und dann die platte klonst).

Wenn die vmware-tools im Gast installiert sind, sorgen die (zumindest bei Windows) dafür, dass vor dem erstellen des Snapshots der Cache geflusht wird, also das Dateisystem auf der Platte wirklich konsistent ist.

Bei Linux ist das aber NICHT der Fall (stand zumindest mal so im Backup-Guide). Du musst also händisch ein pre-freeze-Skript anlegen, dass einmal sync ausführt.

Viel Spaß dabei da gibts anscheinend einige Bugs/Ungereimtheiten zur Doku, wo das Skript liegen muss usw. Drum als Tipp: Bau irgendwas ein, woran Du siehst, dass/ob es wirklich ausgeführt wird.


Wenn das dann klappt, dann solltest Du Dir Gedanken über die Konsistenz der Applikationen (sprich Deiner Datenbanken machen).... Denn die lassen sich im Normalfall auch nicht einfach so im laufenden Betrieb sichern, da gibts entsprechende Backup-Modi, Logs usw.

Viele Grüße,
Jörg

PS.: Wäre schön, wenn Du uns auf dem Laufenden halten würdest, ich glaub, zum Thema Backup und pre-freeze von Linux-Gästen gibts her erst recht wenig.

[continuum]

tauchen im vmware.log disklib Problem auf ?

zur Not poste mal eins

[cicero]

Hi Jörg,

dank für deine Antwort!

/usr/sbin/pre-freeze-scipt und post-thaw-script
hab ich schon im Einsatz.

Sie fährt (nachgewiesen) die Oracle vor dem Snapshot in den Suspend,
bzw Lotus ganz runter und macht anschliessend ein "sync;sync;sync"
damit auch wirklich alles weggeschrieben wird.

Leider ohne Besserung.

viele andere Linux-Gäste lassen sich auf diese weise tadellos sichern.
Ext3 sollte auch robust genug sein, um mit dem power-off klarzukommen?

David

[cicero]

tauchen im vmware.log disklib Problem auf ?

zur Not poste mal eins

meines Erachtens auch keine Probleme im vmware.log des Gasts am ESX wärend des Snapshots oder auch davor.

[Tschoergez]

hmm, wenns bei den anderen Linux-VMs besser klappt (was nutzen die für ein Filesystem?), würd ich wohl als nächstes schauen, was Redhat von den anderen unterscheidet...

Wenn ich Dich richtig verstanden hab, läuift die VM selbst ja ohne Probleme weiter, oder?


Drum in die andere Richtung: Wie sieht denn Dein Ziel der Sicherung aus? Könnte es da Probleme mit NEtzprotokollen... bis hin zu defekten Sektoren auf dem Backupmedium geben?

[continuum]

dumme Frage am Rand - sind die Kernels der Problem-VMs neuer als 2.6.19 ?

[cicero]

- ext3 wird auf allen Linux-Gästen verwendet.
- Probleme gibs bei RHEL 4.3 und beim aktuellen 5.3
- jedoch keine Probleme bei einer Test-VM mit 4.3 Minimal-installation
- die Quell-VM läuft ohne probleme
- da jedoch alle 17 andren Sicherungskopien ohne Probleme laufen,
kann ichs auch nicht aufs Backupmedium/Netzwerk schieben (?)
- Kernel: 2.6.9 und 2.6.18

Vielleicht ist ein Reim drauf zu machen,
die der Problem-Gast P2V auf die ESX kam.

Interessant ist auch, dass es bei den zwei wichtigsten Gästen
mit der größten Datenmenge passiert.

Ich selbst weiss daher nicht mehr, in welche Richtung ich noch testen könnte?

David

[Tschoergez]

schwierig ...

Evtl. mal bei Veeam anfragen, ob deren Produkt irgendwie Probleme macht bei größeren Datenmengen.

Kannst Du irgeneine andere Art des Backups mal ausprobieren?
Wie genau sieht denn Eure Backup-Architektur aus?

[cicero]

jup, hab Veeam schon miteinbezogen.
Sie meinten jedoch, dass Veeam-Seitig alles in Ordnung ist,
und wissen bis auf weiteres auch noch keinen Rat.

Die Architektur in dem Fall ist einfach:
jeden Wochentag werden nächtlich alle Gäste der 3 ESXen
per Veeam Replikation auf einen entfertnen ESX repliziert.
Momentan per Gbit-Lan. Später per 100Mbit Glas 10km entfernt.

5 Generationen das Delta, dann wirds im Radl überschrieben.

-> Ein Cold-Standby-Server, falls eine/alle ESXen/Serverraum warum auch
immer nicht mehr einsatzbereit sind.

David

[ollfried]

Hi,
Was für Fehler wirft der Server denn aus? Und zeig mal bitte "dumpe2fs -h /dev/sda"
Gruß

[cicero]

Hi Ollfried,

auf der root-Partition (scheinbar fasst ausschliesslich darauf (?) )
wirft fsck.ext3 gut 100 dieser Fehlermeldungen auf:

Code: Alles auswählen

"extended atrrribute block 22343 has reference count 3, should be 2. Fix<y>?"

"Invalid inode number for '.' in a directory inode 44454. Fix<y>?"

"Entry 'filename' in /directory/.../???/.../ (99303) has an incorrect filetype(was 1. should be 2)"

"Entry 'filename' in /directory/.../???/.../ (99303) has deleted/unused inode"

"Unconnected directory inode 762765 (/usr/bin/???)

Connect to /lost+found<y>?"

"Block bitmap differences: (24571--24572)..."

"Free blocks count wrong for group #0(201, counted=199)"

"Unattached inode 49249"

"Doppeltet oder unzulässiger Block in Gebrauch"

"i_Blocks ist 12345 sollte sein 22343"



dump2f vor dem fsck:

Code: Alles auswählen

Filesystem volume name:   /
Last mounted on:          <not available>
Filesystem UUID:          498e5ab9-9711-4cc8-8404-0f22465b6f13
Filesystem magic number:  0xEF53
Filesystem revision #:    1 (dynamic)
Filesystem features:      has_journal ext_attr dir_index filetype needs_recovery sparse_super
Filesystem flags:         signed_directory_hash
Default mount options:    (none)
Filesystem state:         clean
Errors behavior:          Continue
Filesystem OS type:       Linux
Inode count:              2396736
Block count:              4781337
Reserved block count:     239602
Free blocks:              1553312
Free inodes:              2155401
First block:              0
Block size:               4096
Fragment size:            4096
Blocks per group:         32768
Fragments per group:      32768
Inodes per group:         16416
Inode blocks per group:   513
Filesystem created:       Tue Jun 27 08:51:13 2006
Last mount time:          Wed Jul 29 20:04:24 2009
Last write time:          Wed Jul 29 20:04:24 2009
Mount count:              2
Maximum mount count:      -1
Last checked:             Sat Jul 25 17:02:36 2009
Check interval:           0 (<none>)
Reserved blocks uid:      0 (user root)
Reserved blocks gid:      0 (group root)
First inode:              11
Inode size:             128
Journal inode:            8
Default directory hash:   tea
Directory Hash Seed:      9b4beba5-4376-4a8b-94f0-92a63502b16b
Journal backup:           inode blocks
Journal size:             32M


und nach dem fsck:

Code: Alles auswählen

Filesystem volume name:   /
Last mounted on:          <not available>
Filesystem UUID:          498e5ab9-9711-4cc8-8404-0f22465b6f13
Filesystem magic number:  0xEF53
Filesystem revision #:    1 (dynamic)
Filesystem features:      has_journal ext_attr dir_index filetype sparse_super
Filesystem flags:         signed_directory_hash
Default mount options:    (none)
Filesystem state:         clean
Errors behavior:          Continue
Filesystem OS type:       Linux
Inode count:              2396736
Block count:              4781337
Reserved block count:     239602
Free blocks:              1547592
Free inodes:              2155161
First block:              0
Block size:               4096
Fragment size:            4096
Blocks per group:         32768
Fragments per group:      32768
Inodes per group:         16416
Inode blocks per group:   513
Filesystem created:       Tue Jun 27 08:51:13 2006
Last mount time:          Fri Jul 31 11:21:30 2009
Last write time:          Fri Jul 31 11:24:46 2009
Mount count:              0
Maximum mount count:      -1
Last checked:             Fri Jul 31 11:24:46 2009
Check interval:           0 (<none>)
Reserved blocks uid:      0 (user root)
Reserved blocks gid:      0 (group root)
First inode:              11
Inode size:             128
Journal inode:            8
Default directory hash:   tea
Directory Hash Seed:      9b4beba5-4376-4a8b-94f0-92a63502b16b
Journal backup:           inode blocks
Journal size:             32M


David[/quote]

[cicero]

... und, wie eben gestestet, tritt der Fehler nicht auf,
wenn ich selbst am Source-Gast das Snapshot VCB-like ziehe und reverte.

kann ich mich nur noch drauf verlassen, dass fsck.ext3 brav aufräumt,
wenn ichs mal brauch...

David