Moin Leute!

Da alles zusammen kommt, 14 auf 15, Einführung pkgbase, mit Auswirkung auf jails, die ich langsam auch als öffentlich erreichbare Server einsetzen möchte und deswegen meine erste Firewall brauchen sollten, und dem Hardwaremangel nur eine M.2 SSD zu haben...

Wie stiegt man idealerweise um, wenn man frisch aufsetzen möchte?

Kann man einen UFS Snapshot anlegen, auf den zpool schieben, und von diesem Backup später die Config auf die neu installierte Umgebung holen?

Tschuess

Kai

--- GoldED+/LNX 1.1.4.7
* Origin: Woran Du glaubst, dafuer sollst Du leben und sterben. (2:240/77)

Hello Kai!

11 Jun 26 13:22, Kai Richter wrote to Alle:

Da alles zusammen kommt, 14 auf 15, Einführung pkgbase, mit
Auswirkung auf jails, die ich langsam auch als öffentlich
erreichbare Server einsetzen möchte und deswegen meine erste
Firewall brauchen sollten, und dem Hardwaremangel nur eine M.2 SSD
zu haben...

So eine M2 ist jetzt nicht so endlos teuer...

Wie stiegt man idealerweise um, wenn man frisch aufsetzen möchte?

Neu installieren?

Kann man einen UFS Snapshot anlegen, auf den zpool schieben, und von diesem Backup später die Config auf die neu installierte Umgebung
holen?

Wie stellst Du Dir "auf den zpool schieben" konkret vor?

PS: BSD-User haben offenbar einfach mehr Spaß...
https://bumsrake.de/


Regards,
Gerrit

... 7:05PM up 552 days, 1:12, 9 users, load averages: 0.71, 0.79, 0.82

--- msged/fbsd 6.3 2021-12-02
* Origin: We are the second generation (2:240/12)

Moin Gerrit!

Am 11 Jun 26, Gerrit Kuehn schrieb an Kai Richter:

So eine M2 ist jetzt nicht so endlos teuer...

Sieh NM, möchte ich gerade vermeiden.

Kann man einen UFS Snapshot anlegen, auf den zpool schieben, und
von diesem Backup später die Config auf die neu installierte
Umgebung holen?

Wie stellst Du Dir "auf den zpool schieben" konkret vor?

Ich habe gestern meinen ersten UFS snapshot vom root device angelegt, da kam eine 60GB Datei raus. Die NAS Daten liegen auf einem raidz Pool, dahin würde ich dann die Snapshot Datei kopieren/verschieben. Anschliessend den Pool exportieren, die Boot M.2 platt machen und FreeBSD 15 neu installieren.

Dann den zpool importieren und dann muss ich nur noch einen weg finden den UFS Snapshot zu öffnen.

PS: BSD-User haben offenbar einfach mehr Spaß...
https://bumsrake.de/

Den laut Footer begründeten technischen Hintergrund verstehe ich nicht, aber das Formulierungsmuster ist gut als dump speech erkennbar. ;-)

Tschuess

Kai

--- GoldED+/LNX 1.1.4.7
* Origin: Freie Bahn fuer Opa Neumann! (2:240/77)

Hello Kai!

12 Jun 26 09:47, Kai Richter wrote to Gerrit Kuehn:

Dann den zpool importieren und dann muss ich nur noch einen weg
finden den UFS Snapshot zu öffnen.

Mit snapshot files unter ufs habe ich schon ewig nicht mehr gearbeitet, aber das Vorgehen ist denke ich recht straight-forward: MemoryDisk anlegen und das Image mounten. Ganz grob also sowas wie

mdconfig -a -t vnode -o readonly -f /var/tmp/mysnapshot
mount -r /dev/md0 /mnt

Kannst Du ja vorher einfach ausprobieren, oder?


Regards,
Gerrit

... 10:06AM up 553 days, 16:13, 9 users, load averages: 1.12, 0.80, 0.77

--- msged/fbsd 6.3 2021-12-02
* Origin: Shock to the System (2:240/12)

Servus Gerrit!

Am 13 Jun 26, Gerrit Kuehn schrieb an Kai Richter:

Mit snapshot files unter ufs habe ich schon ewig nicht mehr
gearbeitet, aber das Vorgehen ist denke ich recht straight-forward: MemoryDisk anlegen und das Image mounten. Ganz grob also sowas wie

Kannst Du ja vorher einfach ausprobieren, oder?

Jupp. Wollte nur wissen ob ich grundsätzlich auf dem richtigen Weg bin.

Ich habe so komische Ideen, zum Beispiel eine Liste aller in den Packages enthaltenen Dateien zu erstellen und diese dann exklusive etc/ als Exclude dem rsnapshot vorzuwerfen. Alles das dabei gesichert wird, sind dann wohl meine Dateien.

Tschuess

Kai

--- GoldED+/LNX 1.1.4.7
* Origin: Das war jetzt wirklich kurz geschrieben. (2:240/77)

Servus Gerrit!

Am 13 Jun 26, Gerrit Kuehn schrieb an Kai Richter:

mdconfig -a -t vnode -o readonly -f /var/tmp/mysnapshot
mount -r /dev/md0 /mnt

Kannst Du ja vorher einfach ausprobieren, oder?

# df -h .
Filesystem Size Used Avail Capacity Mounted on
/dev/nvd0p2 48G 12G 32G 28% /

# ls -l
total 67616
-r--r----- 1 root operator 53687123968 Jun 19 17:37 roottree01
-r--r----- 1 root operator 53687123968 Jun 19 17:38 roottree03

Kopiere snapshot file auf zfs:
i/o error bei ca. 14G. Datei ist nicht per mount lesbar.

:/zfs.backup/# ls -l roo*
# ls -l roo*
-r--r----- 1 root wheel 14922285056 Jun 19 17:13 roottree01
-r--r----- 1 root wheel 14946140160 Jun 19 17:37 roottree03

Schade. Wäre zu einfach gewesen. UFS snapshot scheinen keine aktiven ufs on boot abzudecken.

Tschuess

Kai

--- GoldED+/LNX 1.1.4.7
* Origin: Das war jetzt wirklich kurz geschrieben. (2:240/77)

Hello Kai!

19 Jun 26 17:45, Kai Richter wrote to Gerrit Kuehn:

Kopiere snapshot file auf zfs:
i/o error bei ca. 14G. Datei ist nicht per mount lesbar.

Kommt mir seltsam vor. Wohin kopierst Du und woher kommt der I/O-Error? Kannst Du die Datei komplett fehlerfrei lesen (z.B. cat nach /dev/null)? Alternativ zur Snapshot-Datei könntest Du auch einfach den Inhalt mit rsync o.ä. kopieren.

Schade. Wäre zu einfach gewesen. UFS snapshot scheinen keine aktiven
ufs on boot abzudecken.

Mir fällt nichts ein, warum ein aktives Filesystem da ein Problem sein sollte. Um das als Ursache auszuschließen, könntest Du ein Live-System vom USB-Stick boooten und es damit versuchen.


Regards,
Gerrit

... 11:10AM up 560 days, 17:17, 9 users, load averages: 0.80, 0.70, 0.77

--- msged/fbsd 6.3 2021-12-02
* Origin: So come and try to tell me (2:240/12)

Tach Gerrit!

Am 20 Jun 26, Gerrit Kuehn schrieb an Kai Richter:

Kopiere snapshot file auf zfs:
i/o error bei ca. 14G. Datei ist nicht per mount lesbar.

Kommt mir seltsam vor. Wohin kopierst Du und woher kommt der
I/O-Error?

Der snapshot liegt ja immer im gleichen UFS Dateisystem aus dem er erstellt wurde.

# Device Mountpoint FStype Options Dump Pass#
/dev/nvd0p2 / ufs rw 1 1
/dev/nvd0p3 none swap sw 0 0

Kannst Du die Datei komplett fehlerfrei lesen (z.B. cat
nach /dev/null)?

# cat roottree01 > /dev/null
cat: roottree01: Input/output error

# cp roottree01 /dev/null
cp: roottree01: Input/output error

Ich denke es liegt am lesen vom nvd0. Allerdings habe ich drei snapshots angelegt, alle haben dasselbe Problem.

[3] Exit 1 cp roottree03 /dev/null
0.065u 12.283s 0:49.06 25.1% 14+160k 325044+0io 0pf+0w
[2] - Exit 1 cp roottree02 /dev/null
0.031u 11.754s 0:48.39 24.3% 15+166k 325623+0io 0pf+0w
[1] + Exit 1 cp roottree01 /dev/null
0.039u 11.647s 0:47.54 24.5% 15+165k 323473+0io 0pf+0w

UFS snapshot scheinen keine aktiven ufs on boot abzudecken.

Mir fällt nichts ein, warum ein aktives Filesystem da ein Problem sein sollte. Um das als Ursache auszuschließen, könntest Du ein Live-System
vom USB-Stick boooten und es damit versuchen.

Muss mir mal für einen freien Tag vornehmen. Oder gibt es noch eine andere Methode um ausschliesslich auf die Dateien EINES Dateisystemes zuzugreifen?

Tschuess

Kai

--- GoldED+/LNX 1.1.4.7
* Origin: Das kommt immer darauf an. (2:240/77)

Hello Kai!

21 Jun 26 23:56, Kai Richter wrote to Gerrit Kuehn:

Mir fällt nichts ein, warum ein aktives Filesystem da ein Problem
sein sollte. Um das als Ursache auszuschließen, könntest Du ein
Live-System vom USB-Stick boooten und es damit versuchen.

Muss mir mal für einen freien Tag vornehmen. Oder gibt es noch eine andere Methode um ausschliesslich auf die Dateien EINES
Dateisystemes zuzugreifen?

Du hattest vermutet, daß das aktive Root ein Problem ist. Das wird man nur los, indem man von einem anderen Medium bootet.
Ich würde "intended use", also mount des Snapshot und rsync zum Kopieren, wie erwähnt für eine einfachere Lösung halten.


Regards,
Gerrit

... 5:51PM up 562 days, 23:58, 9 users, load averages: 1.07, 0.78, 0.77

--- msged/fbsd 6.3 2021-12-02
* Origin: And the pastiche we've invented (2:240/12)

Servus Gerrit!

Am 22 Jun 26, Gerrit Kuehn schrieb an Kai Richter:

Du hattest vermutet, daß das aktive Root ein Problem ist. Das wird man
nur los, indem man von einem anderen Medium bootet. Ich würde
"intended use", also mount des Snapshot und rsync zum Kopieren, wie erwähnt für eine einfachere Lösung halten.

Ich habe erstmal ohne Boot mit rsync kopiert, leider unbeaufsichtigt.

sent 25,707,775,922 bytes received 8,875,470 bytes 55,364,158.00 bytes/sec total size is 25,652,388,515 speedup is 1.00
rsync error: some files/attrs were not transferred (see previous errors) (code 23) at main.c(1359) [sender=3.4.1]

Im zweiten Lauf ergab sich diese Situation:

sending incremental file list
var/cache/pkg/curl-7.71.0-cb551eb65f.txz var/cache/pkg/e2fsprogs-1.45.6_3-74b26572e4.txz var/cache/pkg/freetype2-2.10.2-d4957dd883.txz

Das gibt mir jetzt zu denken. Da in der Zwischenzeit kein pkg zu Gange gewesen sein dürfte, macht es keinen Sinn warum diese Dateien neu sein sollten...

SMART/Health Information (NVMe Log 0x02, NSID 0xffffffff)
Critical Warning: 0x00
Temperature: 53 Celsius
Available Spare: 86%
Available Spare Threshold: 10%
Percentage Used: 0%
Data Units Read: 5,497,996 [2.81 TB]
Data Units Written: 7,358,672 [3.76 TB]
Host Read Commands: 213,886,847
Host Write Commands: 105,994,899
Controller Busy Time: 289
Power Cycles: 305
Power On Hours: 67,552
Unsafe Shutdowns: 51
Media and Data Integrity Errors: 136
Error Information Log Entries: 136
Temperature Sensor 1: 53 Celsius
Temperature Sensor 2: 65 Celsius

Error Information (NVMe Log 0x01, 16 of 64 entries)
Num ErrCount SQId CmdId Status PELoc LBA NSID VS Message
0 136 8 0x002d 0xc502 0x000 78617514 1 - Unrecovered Read Error
1 135 5 0x0001 0xc502 0x000 78617514 1 - Unrecovered Read Error

Oh-ohh, da scheint die Migration auf 15 dringender zu sein, als gedacht.

Tschuess

Kai

--- GoldED+/LNX 1.1.4.7
* Origin: Kommt darauf an. (2:240/77)

Hello Kai!

26 Jun 26 20:15, Kai Richter wrote to Gerrit Kuehn:

Error Information (NVMe Log 0x01, 16 of 64 entries)
Num ErrCount SQId CmdId Status PELoc LBA NSID VS
Message
0 136 8 0x002d 0xc502 0x000 78617514 1 - Unrecovered Read Error
1 135 5 0x0001 0xc502 0x000 78617514 1 - Unrecovered Read Error

Oh-ohh, da scheint die Migration auf 15 dringender zu sein, als
gedacht.

So richtig heile sieht das nicht mehr aus. Wenn Du entsprechende Einträge (vielleicht auch im dmesg) zwischen Deinen rsyncs hast, erklärt das das eine oder andere Problem...


Regards,
Gerrit

... 7:55PM up 571 days, 2:02, 9 users, load averages: 0.85, 0.90, 0.87

--- msged/fbsd 6.3 2021-12-02
* Origin: So come and try to tell me (2:240/12)

Moin Gerrit!

Am 30 Jun 26, Gerrit Kuehn schrieb an Kai Richter:

Error Information (NVMe Log 0x01, 16 of 64 entries)
Num ErrCount SQId CmdId Status PELoc LBA NSID
VS Message 0 136 8 0x002d 0xc502 0x000
78617514 1 - Unrecovered Read Error 1

So richtig heile sieht das nicht mehr aus.

Ich konnte das Thema noch nicht angehen und bin jetzt in der Vorbereitung für den SSD Wechsel und Neu-Installation von 15R.

Meiner vagen Erinnerung nach hatte ich inzwischen ein Update mit Reboot und heute sieht smartctl so aus:

=== START OF SMART DATA SECTION ===
SMART overall-health self-assessment test result: PASSED

SMART/Health Information (NVMe Log 0x02, NSID 0xffffffff)
Critical Warning: 0x00
Temperature: 50 Celsius
Available Spare: 86%
Available Spare Threshold: 10%
Percentage Used: 0%
Data Units Read: 5,709,672 [2.92 TB]
Data Units Written: 7,648,765 [3.91 TB]
Host Read Commands: 224,223,141
Host Write Commands: 109,296,921
Controller Busy Time: 300
Power Cycles: 308
Power On Hours: 68,632
Unsafe Shutdowns: 51
Media and Data Integrity Errors: 136
Error Information Log Entries: 136
Warning Comp. Temperature Time: 0
Critical Comp. Temperature Time: 0
Temperature Sensor 1: 50 Celsius
Temperature Sensor 2: 63 Celsius

Error Information (NVMe Log 0x01, 16 of 64 entries)
No Errors Logged


Der Spare ist nicht gesunken. Laut Datenblatt ist die smart Temp 0-70 °C, TBW bei 150TB und 5 Jahre Garantie. Was ich komisch finde, obwohl der error log counter noch bei 136 steht, werden no errors logged angezeigt.

Ich vermute mal die Firmware hat den Spare verwendet um die defekten Bereiche zu ersetzen, denn genau dafür sollte der Spare ja da sein.

Tschuess

Kai

--- GoldED+/LNX 1.1.4.7
* Origin: Schriftverkehr kann man auch ohne Pille riskieren. (2:240/77)