H
Heinrich
Guest
Hallo Leute,
Ich habe hier ein Problem mit einem kaputten ZFS-Pool:
Man sieht, dass eigentlich nur 2 Dateien defekt sind: 6927 und 1d08, allerdings leider auch in allen Snapshots seit dem 19.12.2018.
Z. Zt. Läuft noch ein Scrub, der nach evtl. weiteren defekten Dateien sucht.
Ich könnte nun ein Rollback auf den letzten noch intakten Snapshot versuchen, dabei alle neueren Snapshots löschen.
Meine Frage nun: Habe ich dann auch wieder einen intakten Pool? Oder doch lieber den letzten guten Snapshot auf externe Platte spielen, Pool löschen und (evtl. auf neuer Festplatte) neu kreieren?
Noch ein paar Infos: Der Pool besteht aus nur 1 Platte, ich benutze ZFS hauptsächlich wegen der Snapshot- und Backup-Möglichkeiten. Ausserdem läuft das Ganze unter VMware ESXi-6.5.0-20170104001-standard.
Ich habe hier ein Problem mit einem kaputten ZFS-Pool:
root@fbsdnas [~] # zpool status -xv
pool: bigdata
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: [URL]http://illumos.org/msg/ZFS-8000-8A[/URL]
scan: scrub in progress since Wed Jan 23 17:26:02 2019
864G scanned out of 2.60T at 61.6M/s, 8h18m to go
0 repaired, 32.42% done
config:
NAME STATE READ WRITE CKSUM
bigdata ONLINE 0 0 38
da1p1 ONLINE 0 0 76
errors: Permanent errors have been detected in the following files:
/bigdata/heinrich/newdata/.zfs/snapshot/2019-01-10-03:00:00/store.sparsebundle/bands/6927
/bigdata/heinrich/newdata/.zfs/snapshot/2019-01-19-03:00:00/store.sparsebundle/bands/6927
/bigdata/heinrich/newdata/.zfs/snapshot/2019-01-23-03:00:00/store.sparsebundle/bands/6927
/bigdata/heinrich/newdata/.zfs/snapshot/2019-01-07-03:00:00/store.sparsebundle/bands/6927
<0xf20>:<0xb0143>
<0x1128>:<0x77548>
/bigdata/heinrich/newdata/.zfs/snapshot/2018-12-29-03:00:00/store.sparsebundle/bands/6927
/bigdata/heinrich/newdata/.zfs/snapshot/2018-12-29-03:00:00/store.sparsebundle/bands/1d08
/bigdata/heinrich/newdata/.zfs/snapshot/2019-01-20-03:00:00/store.sparsebundle/bands/6927
/bigdata/heinrich/newdata/store.sparsebundle/bands/6927
/bigdata/heinrich/newdata/store.sparsebundle/bands/1d08
/bigdata/heinrich/newdata/.zfs/snapshot/2018-12-30-03:00:00/store.sparsebundle/bands/1d08
/bigdata/heinrich/newdata/.zfs/snapshot/2018-12-21-03:00:00/store.sparsebundle/bands/6927
/bigdata/heinrich/newdata/.zfs/snapshot/2018-12-21-03:00:00/store.sparsebundle/bands/1d08
/bigdata/heinrich/newdata/.zfs/snapshot/2018-12-26-03:00:00/store.sparsebundle/bands/6927
/bigdata/heinrich/newdata/.zfs/snapshot/2018-12-26-03:00:00/store.sparsebundle/bands/1d08
/bigdata/heinrich/newdata/.zfs/snapshot/2019-01-16-03:00:00/store.sparsebundle/bands/6927
/bigdata/heinrich/newdata/.zfs/snapshot/2019-01-12-03:00:00/store.sparsebundle/bands/6927
<0xf50>:<0xb0143>
/bigdata/heinrich/newdata/.zfs/snapshot/2019-01-21-03:00:00/store.sparsebundle/bands/6927
/bigdata/heinrich/newdata/.zfs/snapshot/2018-12-22-03:00:00/store.sparsebundle/bands/6927
/bigdata/heinrich/newdata/.zfs/snapshot/2018-12-22-03:00:00/store.sparsebundle/bands/1d08
/bigdata/heinrich/newdata/.zfs/snapshot/2019-01-14-03:00:00/store.sparsebundle/bands/6927
/bigdata/heinrich/newdata/.zfs/snapshot/2018-12-27-03:00:00/store.sparsebundle/bands/6927
/bigdata/heinrich/newdata/.zfs/snapshot/2018-12-27-03:00:00/store.sparsebundle/bands/1d08
<0x129e>:<0x77548>
/bigdata/heinrich/newdata/.zfs/snapshot/2019-01-22-03:00:00/store.sparsebundle/bands/6927
/bigdata/heinrich/newdata/.zfs/snapshot/2018-12-23-03:00:00/store.sparsebundle/bands/1d08
/bigdata/heinrich/newdata/.zfs/snapshot/2019-01-04-03:00:00/store.sparsebundle/bands/6927
/bigdata/heinrich/newdata/.zfs/snapshot/2019-01-17-03:00:00/store.sparsebundle/bands/6927
/bigdata/heinrich/newdata/.zfs/snapshot/2018-12-25-03:00:00/store.sparsebundle/bands/6927
/bigdata/heinrich/newdata/.zfs/snapshot/2018-12-25-03:00:00/store.sparsebundle/bands/1d08
/bigdata/heinrich/newdata/.zfs/snapshot/2018-12-28-03:00:00/store.sparsebundle/bands/6927
/bigdata/heinrich/newdata/.zfs/snapshot/2018-12-28-03:00:00/store.sparsebundle/bands/1d08
/bigdata/heinrich/newdata/.zfs/snapshot/2018-12-24-03:00:00/store.sparsebundle/bands/1d08
/bigdata/heinrich/newdata/.zfs/snapshot/2019-01-11-03:00:00/store.sparsebundle/bands/6927
/bigdata/heinrich/newdata/.zfs/snapshot/2018-12-19-03:00:00/store.sparsebundle/bands/1d08
/bigdata/heinrich/newdata/.zfs/snapshot/2019-01-18-03:00:00/store.sparsebundle/bands/6927
/bigdata/heinrich/newdata/.zfs/snapshot/2018-12-20-03:00:00/store.sparsebundle/bands/1d08
root@fbsdnas [~] # uname -a
FreeBSD fbsdnas 11.1-RELEASE FreeBSD 11.1-RELEASE #0 r321309: Fri Jul 21 02:08:28 UTC 2017 [EMAIL]root@releng2.nyi.freebsd.org[/EMAIL]:/usr/obj/usr/src/sys/GENERIC amd64
root@fbsdnas [~] #
Man sieht, dass eigentlich nur 2 Dateien defekt sind: 6927 und 1d08, allerdings leider auch in allen Snapshots seit dem 19.12.2018.
Z. Zt. Läuft noch ein Scrub, der nach evtl. weiteren defekten Dateien sucht.
Ich könnte nun ein Rollback auf den letzten noch intakten Snapshot versuchen, dabei alle neueren Snapshots löschen.
Meine Frage nun: Habe ich dann auch wieder einen intakten Pool? Oder doch lieber den letzten guten Snapshot auf externe Platte spielen, Pool löschen und (evtl. auf neuer Festplatte) neu kreieren?
Noch ein paar Infos: Der Pool besteht aus nur 1 Platte, ich benutze ZFS hauptsächlich wegen der Snapshot- und Backup-Möglichkeiten. Ausserdem läuft das Ganze unter VMware ESXi-6.5.0-20170104001-standard.