OmniOS scrub Fehlermeldung

[esquire1968]

Hallo zusammen!

Habe auf den Befehl „zpool status -v rpool“ folgende Fehlermeldung erhalten:


state: ONLINE
status: One or more devices has experienced an error resulting in data
corruption. Applications may be affected.
action: Restore the file in question if possible. Otherwise restore the
entire pool from backup.
see: http://illumos.org/msg/ZFS-8000-8A
scan: scrub repaired 0 in 0 days 00:00:19 with 2 errors on Mon Mar 2 12:42:35 2020
config:

NAME STATE READ WRITE CKSUM
rpool ONLINE 0 0 2
c1t0d0 ONLINE 0 0 4

errors: Permanent errors have been detected in the following files:

rpool/ROOT/omnios-r151032p-1@2019-02-07-18:29:13:/opt/gcc-7/libexec/gcc/i386-pc-solaris2.11/7.3.0/cc1plus

Allerdings kann ich das File nicht finden. Wie kann ich da vorgehen?

besten Dank vorab.

Gruß
Thomas

 

[ludwinator]

Das ist ein Snapshot, erkennbar an dem @2019....
Rpool ohne Redundanz? Aber hoffentlich mit Backup ?

cu

 

[esquire1968]

Danke für die Antwort. Backup habe ich schon, allerdings schon etwas älter.
Den Snapshot könnte ich doch einfach löschen, dann ist das Problem behoben?
Allerdings finde ich den Snapshot nicht, wo muss ich da suchen?

Verwende napp-it, da kann ich keinen Snapshot von rpool anlegen!?
rpool ohne Redundanz? Wie gehe ich das an?

Gruß
Thomas

 

[besterino]

Man kann prima nachträglich noch einen Datenträger als mirror hinzufügen (jedenfalls unter Solaris, sollte unter den Ablegern auch so sein) - empfehle ich wenn möglich durchaus, lässt ruhiger schlafen.

 

[gea]

Rpool ist ein ZFS Dateisystem. Man kann da auch Snapshots anlegen. Macht aber nur Sinn wenn man Rpool auch für Daten nutzt (macht man eigentlich nicht). Ansonst hat man auf rpool Bootenvironments. Das sind bootfähige Snaps. Kann man auch löschen (Auch Menü Snapshots).

Wenn man eine reine Storage Appliance hat, braucht man eigentlich keinen Boot-Mirror. Eine Neuinstallation dauert Minuten. Man kann die napp-it Settings in /var/web-gui/_log/.* sichern und wiederherstellen (manuell oder Backup-Job) sowie User mit alten uid/gid. Auch kann man das aktuelle BE auf den Datenpool replizieren und wiederherstellen. Ist aber allenfalls Kür, nicht Pflicht.

 

[Ceiber3]

Man kann prima nachträglich noch einen Datenträger als mirror hinzufügen (jedenfalls unter Solaris, sollte unter den Ablegern auch so sein) - empfehle ich wenn möglich durchaus, lässt ruhiger schlafen.

Finde ich persönlich blöd, da ein min wieder eine Festplatte als Speicher wegfällt.

 

[besterino]

OS-Platten müssen bei Solarish nicht größer als 64GB sein (grds. sollten auch 32GB reichen) - und aufm RPOOL gehört sowieso nix gespeichert. Entweder man nimmt da ne kleine her, oder man lässts bleiben. Zwingend ist das nicht. Wie gea schon schrieb, spart man sich halt eine Neuinstallation und ein Einspielen des Backups mit den Einstellungen.

Bei einem virtualisierten Solarish noch eleganter: da kannste mit 2 VMDKs arbeiten und den rpool entweder über verschiedene Teile eines Datenträgers mirrorn (immerhin Schutz vor einem defekten Sektor) oder eben (noch besser) über zwei VMDKs auf zwei physischen Datenträgern, auf denen auch noch andere VMs liegen könnten.

 

[gea]

Es gibt Platten z.B. sind von meinen Intel DC 35x0 die ich hauptsächlich als Bootplatte nutze noch nie welche ausgefallen. Man muss schon sehr hohe Ansprüche an Verfügbarkeit haben, um deswegen einen Bootmirror bei einem Storage only System wie Solaris/OmniOS zu machen. Bei einigen Desktop SSDs mag das anders aussehen.

Ich würde die Bootplatte dennoch größer wählen (ab ca 80GB). Erstens sind swap and dump (System zvols) abhängig von der RAM-Größe. Da der immer größer wird. sollten auch die Bootplatten größer werden (auch wenn man dump als Dokumentation einer Crashursache nur braucht, wenn man dev-Support möchte). Aber allein die Bootumgebungen bei denen man auf frühere Systemstände (vor Update xy oder Stand vor Änderungen) zurückgehen kann, sind Gold wert - brauchen halt Platz

 

[besterino]

Jo, ich benutz halt @home eigentlich fast nur Consumer SSDs und hatte da schon ein paar schlechte Erfahrungen (SanDisk, Transcend). Da ist’s schon nett wenn dir das Herzstück der Infrastruktur wegen so‘nem Mist nicht ausfällt und du einfach eine „bessere“ SSD einschiebst, dadrauf eine neue 2. VMDK ablegst/einhängst und schwupp kurze Zeit später hast Du wieder Redundanz und Seelenfrieden. Kann man übrigens auch prima zum clones der VM verwenden...

Ja - Enterprise Grade SSDs sind natürlich besser. Ich finde vor allem sensationell, wie simpel und schnell es ging, bei Solaris einfach nachträglich das OS redundant auszulegen. Ein Befehl, bisserl warten, fertig. So einfach hab ich das noch nie erlebt... staune quasi immer noch.