:fill(white):strip_exif()/i/2003943496.jpeg?f=thumbmini)
:strip_exif()/i/1321263566.png?f=thumbmini)
:strip_icc():strip_exif()/u/269054/crop6064049cee9ab_cropped.jpg?f=community)
Wie du mir, so ich dir.
:strip_exif()/u/70909/BlueKachina_60x60.gif?f=community)
:strip_icc():strip_exif()/u/71319/crop63827a2053b9b_cropped.jpg?f=community)
:strip_icc():strip_exif()/u/481635/images.jpg?f=community)
/u/23789/icon-apple.png?f=community){kind=icon}
Een van mijn disken in mijn TrueNAS server geeft een issue. Geen gekke dingen te zien in de SMART status, maar wel een pool welke aangeeft niet 'healthy'. te zijn. Geen idee waar ik dit kan fixen. Een scrub lost de issues niet op.
/f/image/otoEVqRhNrZ6EQ6jpMIfqxPM.png?f=fotoalbum_large)
/f/image/emUwsyhxndiqRghSb2Oaa1qK.png?f=fotoalbum_large)
:fill(white):strip_exif()/f/image/otoEVqRhNrZ6EQ6jpMIfqxPM.png?f=user_large)
:fill(white):strip_exif()/f/image/emUwsyhxndiqRghSb2Oaa1qK.png?f=user_large)
... all gonna wonder how you ever thought you could live so large and leave so little for the rest of us...
:strip_exif()/u/396800/D-_3427da0a9c293b63f2a66dea2e642102.gif?f=community)
Zover ik kan zien is er niks aan de hand met de SMART status.
/f/image/P8HBhz1LuCk1eEvlPARgDnUA.png?f=fotoalbum_large)
/f/image/soQVfvTPR8GnN38nNRmphxF8.png?f=fotoalbum_large)
:fill(white):strip_exif()/f/image/P8HBhz1LuCk1eEvlPARgDnUA.png?f=user_large)
:fill(white):strip_exif()/f/image/soQVfvTPR8GnN38nNRmphxF8.png?f=user_large)
... all gonna wonder how you ever thought you could live so large and leave so little for the rest of us...
... all gonna wonder how you ever thought you could live so large and leave so little for the rest of us...
:strip_exif()/u/1054665/crop5be31086906cf_cropped.gif?f=community)
:strip_exif()/u/49248/DPCkoeienUD.gif?f=community)
Ik zou me pas zorgen gaan maken als het vaker gebeurt en die teller flink hoog oploopt!
Dan kan je hopelijk ook wat gerichter bepalen waar het vandaan komt als het ooit zover komt...
|| Stem op mooiere Topic Search linkjes! :) " || Pi-Hole : Geen advertenties meer voor je hele netwerk! >:) ||
... all gonna wonder how you ever thought you could live so large and leave so little for the rest of us...
/u/170728/owl.png?f=community)
Waarom SMR HDD's
Wees blij dat het geen Rebuild was die moest voltooien...
|| Stem op mooiere Topic Search linkjes! :) " || Pi-Hole : Geen advertenties meer voor je hele netwerk! >:) ||
Ik heb hier ook alleen maar SMR HDD's in mijn NAS. De bekende 2.5" Seagate 5TB in een drieweg mirror.:
[...]
Waarom SMR HDD's
Wees blij dat het geen Rebuild was die moest voltooien...
Sinds de 2 dagen regel reageer ik hier niet meer
Omdat ik die in bruikleen kreeg van een heel goede vriend, wiens backups ik hier ook stockeer.:
[...]
Waarom SMR HDD's
Wees blij dat het geen Rebuild was die moest voltooien...
De langere rebuilds kan ik wel hebben, het is ook maar een backupserver. Als die twee weken moet rebuilden kan ik dat prima af.
:strip_icc():strip_exif()/u/74114/tux_tweakers.jpg?f=community)
Zo eindelijk ook zfs in de praktijk gebracht, in 1 woord: wauw, gewoon wauw! Wat zit dit goed in elkaar zeg 
Ja ik wist dat het pas tot zijn recht komt met dedidacted hardware, dat het onder Linux in het algemeen en ReHat in het bijzonder wat haken en ogen heeft en vooral dat het materie is waar je wel even de tijd voor moet nemen.
Goed even dacht ik dat ik toch een major issue had gevonden: podman en libvirt ook, gebruiken het SELinux category attribuut (als ik het nou helemaal goed zeg
) om processen en bestanden met op zich dezelfde SELinux context toch geschieden te houden door nog een extra attribuut toe te voegen. Ik had al eerder gemerkt dat bestaande tooling hier moeite mee heeft, een restorecon -Rv die niets doet maar toch permissie problemen bv. Het motto is geloof ik dat je het maar allemaal aan podman (of libvirt) moet overlaten en dat het dan wel goed komt. Waar heb ik het dan over? Bv de Z optie voor podman volumes die content alleen beschikbaar maakt voor die container, versus lowercase z dat ook SELinux toepast maar dan de volumes deelbaar maakt tussen containers.
Ik liep er tegenaan dat plex juist hierop stuk liep op een eigen dataset binnen mijn ZFS pool, wat op zich al even zoeken was .... was al bezig met zvols en xfs en de tranen stonden bij wijze van spreke al in mijn ogen Wat nou nooit meer partitioneren en gewoon netjes indelen..... Uiteindelijk bleek het natuurlijk en gelukkig gewoon mijn fout: gewoon afblijven van de context opties van zfs en dat allemaal op de default van"none" laten, het OS redt zich er dan wel mee. Gok zelfs dat je dit net als met gewone rechten kan fixen door het mountpoint van de juiste context te voorzien, maar dot vooral dus niet als dataset prop mee te geven!
Wellicht heeft iemand anders hier wat aan, kon hier nl. niet veel over vinden. Sowieso de MLS/MLC optie van SELinux wordt dus wel gebruikt al in het wild op default installaties maar is erg onderbelicht.
Ja ik wist dat het pas tot zijn recht komt met dedidacted hardware, dat het onder Linux in het algemeen en ReHat in het bijzonder wat haken en ogen heeft en vooral dat het materie is waar je wel even de tijd voor moet nemen.
Goed even dacht ik dat ik toch een major issue had gevonden: podman en libvirt ook, gebruiken het SELinux category attribuut (als ik het nou helemaal goed zeg
) om processen en bestanden met op zich dezelfde SELinux context toch geschieden te houden door nog een extra attribuut toe te voegen. Ik had al eerder gemerkt dat bestaande tooling hier moeite mee heeft, een restorecon -Rv die niets doet maar toch permissie problemen bv. Het motto is geloof ik dat je het maar allemaal aan podman (of libvirt) moet overlaten en dat het dan wel goed komt. Waar heb ik het dan over? Bv de Z optie voor podman volumes die content alleen beschikbaar maakt voor die container, versus lowercase z dat ook SELinux toepast maar dan de volumes deelbaar maakt tussen containers.Ik liep er tegenaan dat plex juist hierop stuk liep op een eigen dataset binnen mijn ZFS pool, wat op zich al even zoeken was .... was al bezig met zvols en xfs en de tranen stonden bij wijze van spreke al in mijn ogen
Wat nou nooit meer partitioneren en gewoon netjes indelen..... Uiteindelijk bleek het natuurlijk en gelukkig gewoon mijn fout: gewoon afblijven van de context opties van zfs en dat allemaal op de default van"none" laten, het OS redt zich er dan wel mee. Gok zelfs dat je dit net als met gewone rechten kan fixen door het mountpoint van de juiste context te voorzien, maar dot vooral dus niet als dataset prop mee te geven!Wellicht heeft iemand anders hier wat aan, kon hier nl. niet veel over vinden. Sowieso de MLS/MLC optie van SELinux wordt dus wel gebruikt al in het wild op default installaties maar is erg onderbelicht.
:strip_icc():strip_exif()/u/75828/sid.jpg?f=community)
Dit had ik inderdaad gelezen. Volgens mij heb ik niet dit probleem maar ik had de stappen al doorlopen, mijn /etc/grub.d/10_linux is al aangepast zodat hij direct naar de tank pool verwijst maar dit helpt niet.
Nog niet geprobeerd, bedankt voor de suggestie.
Edit:
Inmiddels opgelost. Ik gebruikte het commando mkinitcpio -p linux terwijl ik de zfs kernel modules alleen voor linux-zen geinstalleerd had en GRUB als default entry Linux-zen gebruikt (en de rest standaard weglaat). Ik had even niet door dat ik mkinitcpio -p linux-zen moest gebruiken en ik had de warnings over het missen van zfs modules over het hoofd gezien omdat het eerder wel werkte. Bedankt in ieder geval voor de suggesties en ik heb weer wat geleerd over het Linux boot process
.
[ Voor 27% gewijzigd door soulcrusher op 20-05-2023 18:36 ]
Ik heb offsite een systeempje draaien dat ZFS datasets van bij mij thuis repliceert (/send & receive dus). Gisteren kreeg ik hiervan een mailtje van een mislukte scrub, dus maar even controleren.
Ik neem aan dat gezien de <0xe2991> dit eerder duid op een metadata error dan op een daadwerkelijke error in een bestand?
Tot voor kort draaide de boel ook in mirror, maar "de andere" HDD (die ~jaartje nieuwer was) is recentelijk overleden en heb ik niet vervangen (kosten/baten, dit specifieke systeempje heeft me meer kopzorgen gegeven dan mijn daadwerkelijke thuisserver). Mogelijk dat er dus wel al langer iets aan de hand was (maar stilletjes gerepareerd? Weet niet of Zed daar over informeerd als die niet verbose draait). Maar puur voor de "theorie" is dit nog te herstellen door bv dit snapshot vanaf de primaire locatie "opnieuw" te versturen? Of kan ik me beter de moeite besparen en deze (bijna) 3 jaar oude snapshot verwijderen? Waarschijnlijk bewaar ik zo'n oude snapshots niet eens meer. Weet niet van welke tool/script dit snapshot is, maar gebruik al een hele tijd Pyznap, en die prefixed snapshots met pyznap_, en zal uiteraard geen andere snapshots aanraken/verwijderen.
errors: Permanent errors have been detected in the following files:
backup/nas/tank/user/robert/data@2020-07-02-000000:<0xe2991>
Ik neem aan dat gezien de <0xe2991> dit eerder duid op een metadata error dan op een daadwerkelijke error in een bestand?
Tot voor kort draaide de boel ook in mirror, maar "de andere" HDD (die ~jaartje nieuwer was
) is recentelijk overleden en heb ik niet vervangen (kosten/baten, dit specifieke systeempje heeft me meer kopzorgen gegeven dan mijn daadwerkelijke thuisserver). Mogelijk dat er dus wel al langer iets aan de hand was (maar stilletjes gerepareerd? Weet niet of Zed daar over informeerd als die niet verbose draait). Maar puur voor de "theorie" is dit nog te herstellen door bv dit snapshot vanaf de primaire locatie "opnieuw" te versturen? Of kan ik me beter de moeite besparen en deze (bijna) 3 jaar oude snapshot verwijderen? Waarschijnlijk bewaar ik zo'n oude snapshots niet eens meer. Weet niet van welke tool/script dit snapshot is, maar gebruik al een hele tijd Pyznap, en die prefixed snapshots met pyznap_, en zal uiteraard geen andere snapshots aanraken/verwijderen.
"Allemaal niet zo dringend en zo"
Dan maar even laten staan totdat 2.2 uit komt en dan pogen nog eens er aan te denken.
Nu even aan het kijken. Deze feature komt pas in 2.2 en die is dus "nog" niet uit
Dan maar even laten staan totdat 2.2 uit komt en dan pogen nog eens er aan te denken.
Het is natuurlijk ook een beetje vaag. In dat die vervolgens faalt op de filename. En met metadata die AFAIK vaker, op meerdere plekken, wordt opgeslagen zou ik ook verwachten dat er meer moet falen? Nu lijkt het maar om een bestand te gaan naar mijn idee. Of i.p.v. op meerdere plekken falen enige indicatie dat er ook iets hersteld is (metadata die op "dezelfde" plek staat die hersteld is vanaf de "kopie"). Terwijl de scrub uit komt op "0B repaired".
Afgaande op de error alleen dat ene snapshot?
Maar experiment of het te herstellen is vind ik eerlijk gezegd belangrijker. En snapshot verwijderen is natuurlijk destructief waarna ik de herstel actie niet meer kan proberen. (Andersom natuurlijk ook, in a way. Als corrective receive werkt en zijn ding doet blijkt ook niet hoeveel snapshots stuk zijn/waren).
Ja true, SSH (client) is natuurlijk maar een optie. Had ik nog niet zo bij stil gestaan. De "met dropbear / SSH server kun je vanaf remote inloggen en invullen" duwde mij meteen in het SSH pad, terwijl lezen met wget etc natuurlijk net zo goed kan. Behalve dat een HTTP endpoint by default weer niet beveiligd is.
Denk dat dat nog even 5 bruggen te ver is
Maar neem aan dat je dus gewoon de kernel boot cmdline bedoelt (dus dat ding dat je in Grub / refind / systemd-boot / ... kunt editten en bij kernel aftrap wordt meegegeven)? (Die in initramfs beschikbaar is als een cmdline.txt naar ik aanneem dan).Maar leest alsof je er ervaring mee hebt. Dus heb je toevallig een opzetje?
Als je wil weten hoe we dat ooit hebben opgezet voor XBian, zie: https://github.com/xbianonpi/xbian-package-initramfs.:
[...]
Denk dat dat nog even 5 bruggen te ver is
Maar leest alsof je er ervaring mee hebt. Dus heb je toevallig een opzetje?
Het parsen van de cmdline.txt t.b.v. een modulaire configuratie van je initramfs:
https://github.com/xbiano...an-initramfs/init#L56-L67
Sinds de 2 dagen regel reageer ik hier niet meer
Hmm, volgens mij ben ik sowieso te moeilijk aan het denken
Gezien het maar om een aantal datasets gaat die niet essentieel zijn "voor het OS" (dus puur user data die er op staat, en dus niet /home, /usr of zo) kan die natuurlijk ook tijdens de normale boot geunlocked worden, middels een systemd unit. By default is er sowieso de zfs-load-key.service die vrij letterlijk de zfs load-key -a doet. Maar in diezelfde fase (After = zfs-import.target, Before = zfs-mount.service & WantedBy = zfs-mount.service) kan ik dus net zo goed een eigen service laten runnen die deze specifieke keys inlaad en "klaar". Dan hoef ik ook nog niet zo, voor mijn idee, tricky te doen met het initramfs image "aanpassen" (/scripts aan toevoegen etc, lastiger debuggen, ...). En door dan de load-key te doen vooraf aan de zfs-mount.service worden ze ook weer automatisch gemount doordat de key beschikbaar is.
Gezien het maar om een aantal datasets gaat die niet essentieel zijn "voor het OS" (dus puur user data die er op staat, en dus niet /home, /usr of zo) kan die natuurlijk ook tijdens de normale boot geunlocked worden, middels een systemd unit. By default is er sowieso de zfs-load-key.service die vrij letterlijk de zfs load-key -a doet. Maar in diezelfde fase (After = zfs-import.target, Before = zfs-mount.service & WantedBy = zfs-mount.service) kan ik dus net zo goed een eigen service laten runnen die deze specifieke keys inlaad en "klaar". Dan hoef ik ook nog niet zo, voor mijn idee, tricky te doen met het initramfs image "aanpassen" (/scripts aan toevoegen etc, lastiger debuggen, ...). En door dan de load-key te doen vooraf aan de zfs-mount.service worden ze ook weer automatisch gemount doordat de key beschikbaar is.
Hmms, blijkt allemaal toch meer voeten in de aarde te hebben. Uiteraard niet stil gestaan bij het feit dat zo vroeg in het boot proces de netwerkverbinding ook nog niet is opgezet. Dus dat lijdt gewoon tot een "could not resolve hostname" en op IP basis "Network is unreachable".:
Hmm, volgens mij ben ik sowieso te moeilijk aan het denken
Gezien het maar om een aantal datasets gaat die niet essentieel zijn "voor het OS" (dus puur user data die er op staat, en dus niet /home, /usr of zo) kan die natuurlijk ook tijdens de normale boot geunlocked worden, middels een systemd unit. By default is er sowieso de zfs-load-key.service die vrij letterlijk de zfs load-key -a doet. Maar in diezelfde fase (After = zfs-import.target, Before = zfs-mount.service & WantedBy = zfs-mount.service) kan ik dus net zo goed een eigen service laten runnen die deze specifieke keys inlaad en "klaar". Dan hoef ik ook nog niet zo, voor mijn idee, tricky te doen met het initramfs image "aanpassen" (/scripts aan toevoegen etc, lastiger debuggen, ...). En door dan de load-key te doen vooraf aan de zfs-mount.service worden ze ook weer automatisch gemount doordat de key beschikbaar is.
Dat wordt dus dit pas uitvoeren na network online. En dan nog een keer een zfs mount -a doen nadat alle keys zijn geladen. Gaat ook om encryption roots met meerdere sub-datasets, dus direct na de load-key een mount van die dataset doen zal de "subsets" niet mounten.
Edit:
Toch makkelijker dan gedacht. Wachten tot het netwerk online is:
INI:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
| [Unit] Description = Load ZFS encryption keys DefaultDependencies = no Wants = network-online.target After = zfs-import.target network-online.target Before = zfs-mount.service [Service] Type = oneshot RemainAfterExit = yes ExecStart=/bin/bash -c 'ssh -i /etc/zfs/ssh_id zfs-keys@192.168.1.1 %i | gpg --batch --decrypt --passphrase-file /boot/zfs-enc-key.txt | zfs load-key %I' ExecStop=zfs unload-key %I [Install] WantedBy = zfs-mount.service |
Oftewel, de Wants & After op network-online.target. Dan werkt het prima.
[ Voor 16% gewijzigd door RobertMe op 23-06-2023 10:11 ]
En toch, klopt ook dit nog niet
Nu ik een sub-dataset heb aangemaakt, die ook nog eens een afwijkend mountpoint heeft (encryption root is rpool/user, nu rpool/user/robert aangemaakt met /home/robert/data als mountpoint).Nu faalt die tijdens de boot weer met een systemd-ask-password prompt. Waarom nu, geen idee. Maar wat dus blijkbaar gebeurt is dat er een "zfs-mount-generator" is. Op basis van een cache file maakt deze (systemd) mount units aan. Daarbij wordt ook gekeken naar de ZFS properties. Heeft de dataset een encroot wordt er een dependency naar zfs-load-key@<encroot> gedefinieerd, en ook daarvoor een service unit gedefinieerd (die op basis van de keylocation weer optioneel dependencies heeft op network-online of local-fs).
Idealiter fix ik dus dat dit gebruik maakt van mijn logica/"script"/commando. Alleen moet ik dan dus puzzelen hoe dat voor elkaar te krijgen. Of worst case org.openzfs.systemd:ignore op on zetten zodat er helemaal niks met dit mount verhaal wordt gedaan.
Problem solved, met deze service unit::
[...]
En toch, klopt ook dit nog niet
Nu faalt die tijdens de boot weer met een systemd-ask-password prompt. Waarom nu, geen idee. Maar wat dus blijkbaar gebeurt is dat er een "zfs-mount-generator" is. Op basis van een cache file maakt deze (systemd) mount units aan. Daarbij wordt ook gekeken naar de ZFS properties. Heeft de dataset een encroot wordt er een dependency naar zfs-load-key@<encroot> gedefinieerd, en ook daarvoor een service unit gedefinieerd (die op basis van de keylocation weer optioneel dependencies heeft op network-online of local-fs).
Idealiter fix ik dus dat dit gebruik maakt van mijn logica/"script"/commando. Alleen moet ik dan dus puzzelen hoe dat voor elkaar te krijgen. Of worst case org.openzfs.systemd:ignore op on zetten zodat er helemaal niks met dit mount verhaal wordt gedaan.
INI:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
| [Unit] Description = Load ZFS encryption keys DefaultDependencies = no Wants = network-online.target After = network-online.target Before = zfs-load-key@%i.service [Service] Type=oneshot RemainAfterExit=yes # This avoids a dependency loop involving systemd-journald.socket if this # dataset is a parent of the root filesystem. StandardOutput=null StandardError=null ExecStart=/bin/bash -c 'ssh -i /etc/zfs/ssh_id zfs-keys@192.168.1.1 %i | gpg --batch --decrypt --passphrase-file /boot/efi/zfs-enc-key.txt | zfs load-key %I' [Install] WantedBy = zfs-load-key@%i.service |
De service depend nu dus alleen op network-online.target, en moet worden uitgevoerd vooraf aan, en is nodig voor, zfs-load-key@%i.service.
Als ik nu dus bv systemctl enable zfs-load-remote-key@rpool-user doe zal deze service automatisch worden uitgevoerd vooraf aan zfs-load-key@rpool-user en zal de key als alles goed is worden ingeladen. Deze vorm zorgt er ook nog eens voor dat de fallback naar de prompt (systemd-ask-password | zfs load-key) blijft werken. Want de door ZFS gegenereerde zfs-load-key@....service controleert eerst de keystatus propery (van de dataset) en doet zijn ding alleen als die unavailable is.
Echter... was dit vrij makkelijk te verzinnen, alleen werkte het niet
. De boot logde een dependency loop op local-fs.target. Oorzaak daarvan is dat de ZFS gegenereerde mount unit dan een WantedBy = local-fs.target heeft, en/maar... network-online.target (dependency van mijn unit) depend op network.target en daarin, blijkbaar, een networking.service zit die ergens stiekem / "onzichtbaar" (niet te zien met systemctl list-dependencies networking.service) ook een dependency naar local-fs.target heeft. Deze unit blijkt vervolgens onderdeel te zijn van Debians ifupdown package en de magic achter /etc/network/{ifup,ifdown,interfaces}.d te zijn. En aangezien ik dat niet gebruik (maar systemd-networkd), dat package verwijderd en dan werkt de boot prima. systemd-networkd leest uiteraard ook config files uit /etc. Maar die heeft een expliciete dependency naar -.mount aka het root filesystem, en dus niet "alle lokale filesystems"
Weet iemand hier een leuke SATA naar USB adapter?
Heb vandaag deze Sabrent ontvangen. Maar uhm, die doet het niet (goed?)
Langer verhaal:
Zoals hier al vaker aangegeven heb ik offsite een OrangePi liggen die backups maakt. Nadat eerder dit jaar een van de twee (Seagate 2,5") schijfjes stuk bleek (in mirror, dus "geen" issue), en later de ander strub failures begon te geven (ook hier over geschreven) maar eens wat ter vervanging gekocht (Samsung 870 Evo 4TB). Ding in mijn NAS gestopt, zpool create backup ata-Samsung-...., ding gevuld. In eerste instantie wilde ik gewoon de SATA - USB adapter van een Seagate schijfje gebruiken, maar... die werken niet lekker met SMART. Daarom bovengenoemde SATA - USB adapter besteld. Maar "die weigert dienst" Als in: de schijf wordt herkent, maar de partities niet (1 & 9 zijn dat dan uit mijn hoofd, bij gebruik volledige schijf). In eerste instantie dacht ik aan faal van block size (geen ashift=12 opgegeven). Met Seagate adapter geeft fdisk een block size van 512 aan, met Sabrent adapter 4096. En dat daardoor wellicht de partitie tabel niet gelezen kon worden. En doordat het sowieso al een faal was geen ashift op te geven maar opnieuw begonnen, alleen dan meteen testen. SSD weer in de NAS geplaatst zpool create backup -o ashift=12 ata-Samsung... -f, netjes geexport, met Sabrent adapter op PC aangesloten, en... niks. /dev/sdc verschijnt wel, maar dus geen partities. Met ook deze mooie output van fdisk:
SSD is intussen dus ook 4x zo groot
Mijn vermoeden is dus dat de adapter de boel niet 1 op 1 doorgeeft? Volgens mij is dat bv een quirk die de adapter in WD Elements HDDs heeft, die snoept ergens wat sectoren op. Maar volgens mij wordt dat dan weer gedetecteerd als corrupte paritietabel? Doordat die aan begin & eind staat? En maar aan 1 kant de sectoren "wegvallen".
Oftewel: mijn vertrouwen in deze adapter ben ik nu al kwijt
Moet ook niet de bedoeling zijn dat ik de SSD dadelijk alleen met deze adapter kan uitlezen en als de adapter stuk gaat de SSD "onbruikbaar" is (geformateerd moet worden).
Edit:
Als "second opinion" maar eens mijn Ewent HDD dock uit gehaald. Die "pakt" hem wel gewoon zoals het hoort.
Heb vandaag deze Sabrent ontvangen. Maar uhm, die doet het niet (goed?)
Langer verhaal:
Zoals hier al vaker aangegeven heb ik offsite een OrangePi liggen die backups maakt. Nadat eerder dit jaar een van de twee (Seagate 2,5") schijfjes stuk bleek (in mirror, dus "geen" issue), en later de ander strub failures begon te geven (ook hier over geschreven) maar eens wat ter vervanging gekocht (Samsung 870 Evo 4TB
). Ding in mijn NAS gestopt, zpool create backup ata-Samsung-...., ding gevuld. In eerste instantie wilde ik gewoon de SATA - USB adapter van een Seagate schijfje gebruiken, maar... die werken niet lekker met SMART. Daarom bovengenoemde SATA - USB adapter besteld. Maar "die weigert dienst" Als in: de schijf wordt herkent, maar de partities niet (1 & 9 zijn dat dan uit mijn hoofd, bij gebruik volledige schijf). In eerste instantie dacht ik aan faal van block size (geen ashift=12 opgegeven). Met Seagate adapter geeft fdisk een block size van 512 aan, met Sabrent adapter 4096. En dat daardoor wellicht de partitie tabel niet gelezen kon worden. En doordat het sowieso al een faal was geen ashift op te geven maar opnieuw begonnen, alleen dan meteen testen. SSD weer in de NAS geplaatst zpool create backup -o ashift=12 ata-Samsung... -f, netjes geexport, met Sabrent adapter op PC aangesloten, en... niks. /dev/sdc verschijnt wel, maar dus geen partities. Met ook deze mooie output van fdisk:`--> sudo fdisk -l /dev/sdc Disk /dev/sdc: 3,64 TiB, 4000787030016 bytes, 976754646 sectors Disk model: Units: sectors of 1 * 4096 = 4096 bytes Sector size (logical/physical): 4096 bytes / 4096 bytes I/O size (minimum/optimal): 32768 bytes / 32768 bytes Disklabel type: dos Disk identifier: 0x00000000 Device Boot Start End Sectors Size Id Type /dev/sdc1 1 4294967295 4294967295 16T ee GPT
SSD is intussen dus ook 4x zo groot
Mijn vermoeden is dus dat de adapter de boel niet 1 op 1 doorgeeft? Volgens mij is dat bv een quirk die de adapter in WD Elements HDDs heeft, die snoept ergens wat sectoren op. Maar volgens mij wordt dat dan weer gedetecteerd als corrupte paritietabel? Doordat die aan begin & eind staat? En maar aan 1 kant de sectoren "wegvallen".
Oftewel: mijn vertrouwen in deze adapter ben ik nu al kwijt
Moet ook niet de bedoeling zijn dat ik de SSD dadelijk alleen met deze adapter kan uitlezen en als de adapter stuk gaat de SSD "onbruikbaar" is (geformateerd moet worden).Edit:
Als "second opinion" maar eens mijn Ewent HDD dock uit gehaald. Die "pakt" hem wel gewoon zoals het hoort.
/u/137180/TS4YTL60R.png?f=community)
:strip_exif()/u/340453/crop67a669ce4f1f4_cropped.webp?f=community)
ZFS doet bij een reboot een `zfs mount -a` maar niet tijdens het wijzigen van je mountpoints inderdaad, dan moet je die handmatig even zelf doen
Even niets...
Je hebt helemaal gelijk, mijn `zfs mount -a` was een sterke vereenvoudiging van het proces
Dat is met de jaren sterk verbeterd in ZoL gelukkig.
Even niets...
Ik zat er wat mee te worstelen, hopelijk heeft de volgende er wat aan, zoniet ga ik het hier ooit wel terugvinden want dit is ook een beetje mijn kennisdatabank ;-)
Ik heb altijd mijn disks gepartitioneerd volgens de guide van @FireDrunk , helaas is die recent verdwenen door het verdwijnen van Tweakblogs, dus voor de volledigheid geef ik die hier ook nog even mee via waybackmachine:
Ik had niet veel zin om manueel partities te zitten gaan aanpassen dus was op zoek naar een eenvoudig commando/manier om de partities te resizen. Via Gparted was geen oplossing (kan geen ZFS partities resizen) maar uiteindelijk bleed parted wel de oplossing te bieden en dan zelfs nog heel eenvoudig:
Ik heb altijd mijn disks gepartitioneerd volgens de guide van @FireDrunk , helaas is die recent verdwenen door het verdwijnen van Tweakblogs, dus voor de volledigheid geef ik die hier ook nog even mee via waybackmachine:
"Probleem" of gevolg van mijn risicobeperking was dat ik bij mijn uitbreiding van 12TB naar 20TB ook op de 20TB disks partities had aangemaakt die even groot waren als de partities op de 12TB, zodat als er toch problemen waren ik niet vast zat en snel 1 oude disk terug in dienst kon stellen.De meest aan mij gestelde vraag de afgelopen tijd is wel: "Hoe richt ik mijn schijven nou in onder Linux als ik ZFS wil gebruiken?".
Dat is eigenlijk heel simpel: met gdisk!
Gdisk is eigenlijk fdisk, maar dan (fatsoenlijk) geschikt voor GPT partities.
apt-get install gdisk
Let op: SOMMIGE WIJZIGINGEN MET GDISK ZIJN DIRECT VAN TOEPASSING, EN HOEF JE DUS NIET MEER TE BEVESTIGEN, LET DUS OP DAT JE DE GOEDE DISK KIEST!
Je kan een disk gewoon aanspreken via zijn standaard linux Identifier.
gdisk /dev/sdb
Kies optie O voor nieuwe GPT layout.
Kies optie N voor een nieuwe partitie.
Partition Number
Druk op [enter] omdat we het standaard Partitienummer willen.
First Sector
Kies hier voor +2M, dat zorgt er voor dat je een offset hebt van 2MB wat eigenlijk altijd goed is om een fatsoenlijke alignment te krijgen.
Last Sector
Je kan hier kiezen wat je wil, voor SSD's kan je hier iets als +50G kiezen, voor hardeschijven kan je hier iets als +3.5T kiezen, het is maar net wat je zelf wil.
Partition Type:
We kiezen hier voor FreeBSD ZFS, omdat Linux geen eigen ZFS partitie ID heeft, (en dat is ook helemaal niet nodig, want ZFSonLinux herkend gewoon FreeBSD ZFS partities
Als het goed is kom je nu weer terug in het hoofdmenu, en kan je met p zien dat je schijf een partitie bevat!
Nu gaan we deze een GPT naam geven zodat deze straks herkenbaar is in je Operating System en ZFS.
Kies in het menu voor optie c en kies de partitie die je wil hernoemen (of een nieuwe naam wil geven) als je maar 1 partitie hebt, neemt gdisk aan dat je die partitie bedoeld en zal je geen keuze meer geven.
Mijn advies: Zet het serienummer van de schijf (of een gedeelte er van) in de naam! Op die manier weet je precies welke schijf er kapot is als je ooit problemen ondervindt!
Je kan het serienummer van een schijf achterhalen met het commando:
hdparm -i /dev/sda | grep SerialNo
Je krijgt dan het type van de schijf, de firmwareversie en het serienummer.
root@NAS:~# hdparm -i /dev/sda | grep SerialNo
Model=ST4000DM000-1F2168, FwRev=CC51, SerialNo=Z3009899
Als voorbeeld zou je dus: DATAPOOL-A-Z3009899 als naam kunnen gebruiken.
Druk op enter om de naam te bevestigen.
Kies daarna voor w om de wijzigingen door te voeren op de schijf.
Herhaal bovenstaande stappen tot je alle partities hebt aangemaakt.
Om nu een mooie pool te maken met ZFS kunnen we de partities benaderen via hun naam!
En wel zo:
zpool create datapool raidz /dev/disk/by-partlabel/DATAPOOL-A-Z3009899 /dev/disk/by-partlabel/DATAPOOL-B-Z3009891 /dev/disk/by-partlabel/DATAPOOL-C-Z3009892 /dev/disk/by-partlabel/DATAPOOL-D-Z3009893 /dev/disk/by-partlabel/DATAPOOL-E-Z3009894
Als je het op deze manier doet zie je in zpool status -v
pool: datapool
state: ONLINE
config:
NAME STATE READ WRITE CKSUM
datapool ONLINE 0 0 0
raidz1-0 ONLINE 0 0 0
datapool-A-Z3009899 ONLINE 0 0 0
datapool-B-Z3009891 ONLINE 0 0 0
datapool-C-Z3009892 ONLINE 0 0 0
datapool-D-Z3009893 ONLINE 0 0 0
datapool-E-Z3009894 ONLINE 0 0 0
errors: No known data errors
En is je ZFS pool klaar voor gebruik!
Ik had niet veel zin om manueel partities te zitten gaan aanpassen dus was op zoek naar een eenvoudig commando/manier om de partities te resizen. Via Gparted was geen oplossing (kan geen ZFS partities resizen) maar uiteindelijk bleed parted wel de oplossing te bieden en dan zelfs nog heel eenvoudig:
parted /dev/sde resizepart 1 100%
Bij deze wel even een bevestiging dat bij het manueel aanpassen van partitie grootte middels bijv. fdisk het ook gewoon werkt
Regelmatig zo gedaan.
Sinds de 2 dagen regel reageer ik hier niet meer
Kopen jullie dan niet altijd grotere schijven?
In 2020 3x 8TB in een RAIDZ pool gezet. In 2021 een vervangen door een 14TB model, in 2022 eentje vervangen door een 18TB model. Met de prime days nu vergeten te kijken of ze weer in de aanbieding waren.
Dan kan ik en geen last hebben van "allemaal uit dezelfde batch en hetzelfde gebruikt" en beetje bij beetje zou uiteindelijk de pool kunnen resizen (als laatste 8TB vervangen is, door dan waarschijnlijk 18TB+, komt er netto dus ~12TB bij), en ik hoef niet weer alles in een keer te vervangen.
En v.w.b. dezelfde (grote) schijven die toch verschillen: ik meen eens gelezen te hebben dat dat of een broodje aap was en ze wel altijd identieke aantal sectoren hebben, en dat ZFS, als je hele HDD opgeeft, daar ook al rekening mee houd (aangezien die alsnog de HDD formateerd en dan ook net iets minder sectoren gebruikt).
10GB ruimte vrijhouden lijkt mij in ieder geval sowieso zwaar overdreven. Áls er al een afwijking is zal dat in de orde van KBs of MBs zijn. Tenzij je bewust iets anders koopt (Pricewatch staan IIRC SSDs in van 2TB en 1,98TB. Dan weet je natuurlijk dat het verschil er is. Maar twee verschillende die beiden als 2TB verkocht worden zal niet een enkele GBs kleiner bij zijn. En die 10GB ongebruikte ruimte helpt in dit geval ook niet).
In 2020 3x 8TB in een RAIDZ pool gezet. In 2021 een vervangen door een 14TB model, in 2022 eentje vervangen door een 18TB model. Met de prime days nu vergeten te kijken of ze weer in de aanbieding waren.
Dan kan ik en geen last hebben van "allemaal uit dezelfde batch en hetzelfde gebruikt" en beetje bij beetje zou uiteindelijk de pool kunnen resizen (als laatste 8TB vervangen is, door dan waarschijnlijk 18TB+, komt er netto dus ~12TB bij), en ik hoef niet weer alles in een keer te vervangen.
En v.w.b. dezelfde (grote) schijven die toch verschillen: ik meen eens gelezen te hebben dat dat of een broodje aap was en ze wel altijd identieke aantal sectoren hebben, en dat ZFS, als je hele HDD opgeeft, daar ook al rekening mee houd (aangezien die alsnog de HDD formateerd en dan ook net iets minder sectoren gebruikt).
10GB ruimte vrijhouden lijkt mij in ieder geval sowieso zwaar overdreven. Áls er al een afwijking is zal dat in de orde van KBs of MBs zijn. Tenzij je bewust iets anders koopt (Pricewatch staan IIRC SSDs in van 2TB en 1,98TB. Dan weet je natuurlijk dat het verschil er is. Maar twee verschillende die beiden als 2TB verkocht worden zal niet een enkele GBs kleiner bij zijn. En die 10GB ongebruikte ruimte helpt in dit geval ook niet).
Ik gebruik nu op mijn server zfs-auto-snapshot, deze snapshots stuur ik handmatig door middel van zfs send and receive naar een andere ssd op de server, via ssh naar een tweede server en om de zoveel tijd ook nog eens naar een externe harde schijf.
Werkt op zich prima, maar het vergt wel een beetje discipline. Heeft iemand nog een goede tip om zfs snapshots automatisch te backuppen?
Werkt op zich prima, maar het vergt wel een beetje discipline. Heeft iemand nog een goede tip om zfs snapshots automatisch te backuppen?
Ik gebruik sanoid om automatisch backups te maken, en @HyperBart haalt ze hier via SSH & ZFS receive automatisch op. Volgens mij ging dat ook met sanoid, maar ik kan het mis hebben.:
Ik gebruik nu op mijn server zfs-auto-snapshot, deze snapshots stuur ik handmatig door middel van zfs send and receive naar een andere ssd op de server, via ssh naar een tweede server en om de zoveel tijd ook nog eens naar een externe harde schijf.
Werkt op zich prima, maar het vergt wel een beetje discipline. Heeft iemand nog een goede tip om zfs snapshots automatisch te backuppen?
Even niets...
Sanoid sluit inderdaad goed bij mijn wensen aan. Ik heb momenteel zfs-auto-snapshot uitgezet/verwijderd en Sanoid ingesteld. Even de komende dagen kijken hoe dat uitpakt...
Sanoid doet automatische snapshotting, dus dat is je vervanger voor ZFS auto snapshot.:
Sanoid sluit inderdaad goed bij mijn wensen aan. Ik heb momenteel zfs-auto-snapshot uitgezet/verwijderd en Sanoid ingesteld. Even de komende dagen kijken hoe dat uitpakt...
Syncoid vult het gat op wat je nu nog manueel doet: snapshotjes overpompen.
En. Dat. Werkt. Magnifiek.
Die setup die je beschrijft is zelfs bijna een van de demo cases dacht ik. Alleen de externe hdd detectie weet ik niet.
De server in het tuinhuis/schuur gaat 45 min per dag aan via een geschakelde klok, doet zijn ding met least privilege en zfs permissions, schrijft een logje weg naar de server die gebackupped wordt en sluit zich netjes af. Als er iets is gooi ik het door naar een Telegram script.
Echt boilerplate sequentieel scriptje, ik ben geen coder en ik ben geen held in Bash maar een paar ifjes en datjes kan ik wel 🫣
[ Voor 35% gewijzigd door HyperBart op 05-08-2023 15:02 ]
/u/116997/mozilla2.png?f=community)
Jep, het is idd prachtig.:
[...]
Syncoid vult het gat op wat je nu nog manueel doet: snapshotjes overpompen.
En. Dat. Werkt. Magnifiek.
Hier mijn script, wat dagelijks via een systemd timer wordt afgetrapt.
Via wake-on-lan wordt de target eerst gewekt. Na de backup wordt de target weer in suspend gezet.
code:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
| #!/bin/sh set -e # Any subsequent(*) commands which fail will cause the shell script to exit immediately echo "Waking up backup.lan via WoL" wakeonlan <mac:ad:res> echo "Wait 10 seconds" sleep 10 #target: USER=koos HOST=backup.lan # alleen datasets opnemen waarvan ook daadwerkelijk backups worden gemaakt. dus skip bijvoorbeeld zfspool/koos! echo "Sending snapshots of koos/configuration" syncoid --no-sync-snap zfspool/koos/configuration $USER@$HOST:zfspool2/koos/configuration --no-privilege-elevation echo "Sending snapshots of koos/documents" syncoid --no-sync-snap zfspool/koos/documents $USER@$HOST:zfspool2/koos/documents --no-privilege-elevation echo "Sending snapshots of koos/home" syncoid --no-sync-snap zfspool/koos/home $USER@$HOST:zfspool2/koos/home --no-privilege-elevation echo "Sending snapshots of koos/kubernetes" syncoid --no-sync-snap zfspool/koos/kubernetes $USER@$HOST:zfspool2/koos/kubernetes --no-privilege-elevation echo "Sending snapshots of koos/macbook" syncoid --no-sync-snap zfspool/koos/macbook $USER@$HOST:zfspool2/koos/macbook --no-privilege-elevation echo "Sending snapshots of koos/photos" syncoid --no-sync-snap zfspool/koos/photos $USER@$HOST:zfspool2/koos/photos --no-privilege-elevation echo "Sending snapshots of koos/videos" syncoid --no-sync-snap zfspool/koos/videos $USER@$HOST:zfspool2/koos/videos --no-privilege-elevation echo "Sending snapshots of koos/books" syncoid --no-sync-snap zfspool/koos/books $USER@$HOST:zfspool2/koos/books --no-privilege-elevation echo "Sending snapshots of koos/zfsmngmnt" syncoid --no-sync-snap zfspool/koos/zfsmngmnt $USER@$HOST:zfspool2/koos/zfsmngmnt --no-privilege-elevation echo "Finished sending snapshots to $HOST" echo "Suspending $HOST" #now suspend the backup target: ssh koos@backup.lan -t 'sudo systemctl suspend' echo "Done." |
Systemd service:
code:
1
2
3
4
5
6
7
| [Unit] Description=Run syncoid OnFailure=email-notification@%i.service [Service] Type=simple ExecStart=/zfspool/koos/configuration/storage-server/syncoid/backup.sh |
Zoals je ziet: bij een failure word ik via een email hierop geattendeerd:
code:
1
2
3
4
5
6
| [Unit] Description=%i failure email notification [Service] Type=oneshot ExecStart=/bin/bash -c ' ( echo "Subject: [%i] failure notification" & /bin/systemctl status %i ) | ssmtp -vvv koos@kaspe.rs -f root@storage ' |
Dat voorbeeld staat trouwens exact boven jouw post
"Hoe laat ik syncoid periodiek uitvoeren?" => zie de post boven de vraag
Ja, ik zie het, maar soms is het even abracadabra voor mij. Het zag er voor mij te moeilijk uit, maar nu begint het langzaam te dagen.:
[...]
Dat voorbeeld staat trouwens exact boven jouw post
Nouja, gezien @GioStyle het rootless wilt draaien... Uiteraard kan cron ook onder een andere user het commando uitvoeren. Maar als dan toch gepuzzeld moet worden daarop kan het zijstapje naar systemd stuff ook wel erbij
Scheelt ook weer het draaien van extra software en potentieel dus iets zuiniger Gezien GioStyle ook in zuinige server topic rond hangt.
Alles hier in cron hoor, zonder root.:
[...]
Nouja, gezien @GioStyle het rootless wilt draaien... Uiteraard kan cron ook onder een andere user het commando uitvoeren. Maar als dan toch gepuzzeld moet worden daarop kan het zijstapje naar systemd stuff ook wel erbij
Heb wel wat permissions moeten geven aan de user die ik er voor aangemaakt had.
Ik vind het hier thuis echt een heel elegante oplossing: offline automated backup, van de stroom af en alles met unattended upgrades wordt gepatched.
Ik kan nu met een gerust hart zeggen: ik heb backups op orde.
Al moeten we nog altijd eens een restore-test doen he @FireDrunk
Restoretest kan alleen als jij mij weer toegang geeft tot de data
Dat is het nadeel van een 'pickup'-ssh user. Je kan niet remote weer bij je backup.
Dat is het nadeel van een 'pickup'-ssh user. Je kan niet remote weer bij je backup.
Even niets...
Ik schreef ook niet dat het niet kon. Alleen zou het voor mij (meer) uitzoek werk zijn. Bij systemd weet ik dat ik maar User=pietje toe hoef te voegen in de service unit file. En als GioStyle nog onbekend is / zou zijn met cron en met systemd (hiervoor) dan lijkt mij dat ee opgedane kennis v.w.b. veel breder toepasbaar is (immers kun je met services ook gewoon software starten tijdens boot ("maar dat kan cron ook met @reboot"), dependencies opgeven om een start volgorde te hebben (en dat kan cron niet)).
Is het trouwens uberhaupt niet raar dat je een cron gebruikt om iets uit te voeren op een systeem dat altijd uit staat?
Je wilt nu toch gewoon dat het wordt uitgevoerd tijdens boot (dus "@reboot")? Dan was een init script (of systemd service unit) toch logischer? En hoefde die systemd service unit nog maar periodiek afgetrapt te worden door een systemd timer Overigens is leuke feature van systemd timers die cron AFAIK niet dat timers persistent kunnen zijn. Dan slaat die de volgende runtime echt op en als het systeem opstart worden de (persistent) timers die die in het verleden uitgevoerd hadden moeten worden alsnog uitgevoerd. Dus bv een timer met "elke maandag om 10 uur" en dat dan net het systeem uit staat wordt netjes ingehaald de volgende boot. Bij cron kan dat AFAIK niet en zou die het pas een week later gebeuren, of dus dubbele regel met een keer een @reboot, maar dan wordt het (bij boots) dus extra uitgevoerd terwijl het niet nodig is.
Stom. zpool clear heeft natuurlijk betrekking op fouten met de disk / vdev of communicatie. Terwijl het in dit geval op een data fout gaat. Dus dat doet niks. Mogelijk had die er wel een disk fout van gemaakt in een mirror / raidz opstelling? En ieder geval had het dan waarschijnlijk geen permanent error opgeleverd, als het om een communicatie fout ging.
Overigens zou ik als het goed is wel een offsite backup hiervan moeten hebben. Naast dat hier alleen data in staat die via SyncThing gevuld wordt en de bron (PC/laptop) zowel rechtstreeks naar dit "servertje" schrijft als naar mijn oude "server" die nu alleen als nas dienst doet. Dus ook buiten ZFS snapshots en send & receive staat de data op twee plekken. Dus daar ook maar eens in neuzen.
Jammer dat ZFS 2.2 nog niet uit is (/in RC en dus nog zeer zeker niet in Debian stable repos). Dan kon ik de corrective receive (mogelijk) proberen. Waarbij ik een tijd terug een ZFS fout had op offsite HDD, waarbij ik op deze corrective receive ben gewezen in dit topic. HDD is intussen vervangen (SMART begon te rammelen, bad sectors), door een SSD, maar heb de HDD wel nog liggen om tzt eens wat te proberen met die corrective receive.
Wat ik in de case at hand wellicht kan doen is het snapshot gewoon verwijderen en opnieuw scrubben (?). Daily snapshots bewaar ik sowieso niet lang. Als zonder dit snapshot de scrub op een ander (/snapshot van vandaag) begint te rammelen is er duidelijk meer aan de hand. Maar ik verwacht dat een (checksum) fout tijdens de scrub (onterecht) als permanent is aangemerkt en niet meer "cleared" for whatever reason. Ook gezien:
Aldus smartctl. Anders had ik ook ergens wel iets in SMART verwacht.
Gezien het format blijkbaar [dataset / snapshot]:[inode / filename] is, lijkt mij dat die met 0x0 juist naar iets anders dan een (oude) file verwijst? Ik zou dan eerder verwachten dat 0x0 een plekje in de metadata is.
Overigens zou ik als het goed is wel een offsite backup hiervan moeten hebben. Naast dat hier alleen data in staat die via SyncThing gevuld wordt en de bron (PC/laptop) zowel rechtstreeks naar dit "servertje" schrijft als naar mijn oude "server" die nu alleen als nas dienst doet. Dus ook buiten ZFS snapshots en send & receive staat de data op twee plekken. Dus daar ook maar eens in neuzen.
Jammer dat ZFS 2.2 nog niet uit is (/in RC en dus nog zeer zeker niet in Debian stable repos). Dan kon ik de corrective receive (mogelijk) proberen
. Waarbij ik een tijd terug een ZFS fout had op offsite HDD, waarbij ik op deze corrective receive ben gewezen in dit topic. HDD is intussen vervangen (SMART begon te rammelen, bad sectors), door een SSD, maar heb de HDD wel nog liggen om tzt eens wat te proberen met die corrective receive.Wat ik in de case at hand wellicht kan doen is het snapshot gewoon verwijderen en opnieuw scrubben (?). Daily snapshots bewaar ik sowieso niet lang. Als zonder dit snapshot de scrub op een ander (/snapshot van vandaag) begint te rammelen is er duidelijk meer aan de hand. Maar ik verwacht dat een (checksum) fout tijdens de scrub (onterecht) als permanent is aangemerkt en niet meer "cleared" for whatever reason. Ook gezien:
code:
1
2
3
4
5
| Media and Data Integrity Errors: 0 Error Information Log Entries: 0 ... Error Information (NVMe Log 0x01, 16 of 64 entries) No Errors Logged |
Aldus smartctl. Anders had ik ook ergens wel iets in SMART verwacht.
Hmm, blijkbaar is er toch wel iets ernstigers aan de hand:
Maar er overheen springen werkt wel:
| cat > /dev/null omdat die anders een invalid argument error geeft. Rechtstreeks outputten naar /dev/null mag niet waarbij meteen deze workaround als suggestie wordt gegeven.
En dit op basis van dat offsite ook de snapshots van deze dataset missen sinds het bewuste moment / snapshot dus. ZFS krijgt het snapshot dus echt niet meer verwerkt. En daardoor heb ik offsite geen backups meer sinds dat moment waarvan ik niet op de hoogte ben gebracht (mijn fout, geen monitoring, en pyznap rammelt sowieso een beetje. Die geeft altijd een succes status, ook als een of meerdere datasets errors gaven)
Dus @FireDrunk, ik doelde met metadata op snapshot metadata, wat dan dus de door jouw genoemde superblocks zijn? En daar lijkt dus ook daadwerkelijk wat te rammelen.
code:
1
2
| `--> sudo zfs send rpool/user/<knip>@pyznap_2023-08-12_00:00:02_daily | cat > /dev/null warning: cannot send 'rpool/user/<knip>@pyznap_2023-08-12_00:00:02_daily': Input/output error |
Maar er overheen springen werkt wel:
code:
1
| `--> sudo zfs send -i rpool/user/<knip>@pyznap_2023-08-11_00:00:02_daily rpool/user/<knip>@pyznap_2023-08-13_00:00:02_daily | cat > /dev/nul |
| cat > /dev/null omdat die anders een invalid argument error geeft. Rechtstreeks outputten naar /dev/null mag niet waarbij meteen deze workaround als suggestie wordt gegeven.
En dit op basis van dat offsite ook de snapshots van deze dataset missen sinds het bewuste moment / snapshot dus. ZFS krijgt het snapshot dus echt niet meer verwerkt. En daardoor heb ik offsite geen backups meer sinds dat moment waarvan ik niet op de hoogte ben gebracht
(mijn fout, geen monitoring, en pyznap rammelt sowieso een beetje. Die geeft altijd een succes status, ook als een of meerdere datasets errors gaven)Dus @FireDrunk, ik doelde met metadata op snapshot metadata, wat dan dus de door jouw genoemde superblocks zijn? En daar lijkt dus ook daadwerkelijk wat te rammelen.
Dus... snapshot verwijderd, scrub gedaan:
Dat wordt zeker de hele pool "dumpen" naar een file / andere drive, en op deze drive een nieuwe pool maken en de hele shebang weer terug zetten vanaf de file. * RobertMe is not amused.
code:
1
2
3
| errors: Permanent errors have been detected in the following files:
<0x7c6b>:<0x0> |
Dat wordt zeker de hele pool "dumpen" naar een file / andere drive, en op deze drive een nieuwe pool maken en de hele shebang weer terug zetten vanaf de file. * RobertMe is not amused.
Als je een realtime input/output error krijgt, kan ZFS het intern ook niet oplossen, dat is wel heel gek, want alle metadata zou redundant moeten zijn 
Je mag het snapshot in kwestie niet verwijderen?
Je mag het snapshot in kwestie niet verwijderen?
Even niets...
Just to be sure, gezien waarschijnlijk gekruist: RobertMe in "Het grote ZFS topic":
Als je een realtime input/output error krijgt, kan ZFS het intern ook niet oplossen, dat is wel heel gek, want alle metadata zou redundant moeten zijn
Je mag het snapshot in kwestie niet verwijderen?