SD kártyán futó Linux mentése

 ( virtualm | 2019. március 12., kedd - 20:04 )

Sziasztok !

Raspberry Pi 3B+ környezetben milyen mentési módszert, programot ajánlotok, ha USB-HD és LAN-PC mentési lehetőség is szóbajöhet.

Nem szeretném a micro SD kártyát kiszedegetni, cserélgetni, hanem alkalomszerűen menteném a kártya tartalmát úgy, hogy egy bootolható, használható rendszert kapjak a mentés végén.

Az elmúlt hetek- hónapok nyüglődései során kialakult rendszerkörnyezetet nem szeretném elveszíteni és újracsinálni mert kihullana a hajam.

Hozzászólás megjelenítési lehetőségek

A választott hozzászólás megjelenítési mód a „Beállítás” gombbal rögzíthető.

dd?

-fs-
Az olyan tárgyakat, amik képesek az mc futtatására, munkaeszköznek nevezzük.

Köszi, ez egy jó, de nem praktikus megoldás lenne.

"Célszerű, hogy a menteni kívánt partíció, vagy egész meghajtó ne legyen használatban, ne legyen mountolva, valamint a mentés nem készülhet arra a partícióra, amelyikről a mentés készül."
--
üdv: virtualm

„úgy, hogy egy bootolható, használható rendszert kapjak a mentés végén”
Ehhez azért dd fog kelleni...
Legalább is ha a partíciós táblát és az MBR-t akarod menteni.
A filerendszer-t viheted akármivel. cp tar+netcat, rsync...

A pín szerintem nem nagyon van mbr. Tök másképp bootol. Megkockáztatom hogy az rsync vagy az *fsdump pont elég, csak a nyitott/írt fájlokkal kell megküzdeni. A cink az, ha az fs/os/rencer nem a sd kártyán van, hanem image-ben, és mellé írja a deltákat. Istennek se ugrik be ennek a neve, pedig csináltam ilyet...

Természetesen azon is van MBR, az a lemez része.
Csak a Pi nem használja bootolásra.

Jogos, jogos :) Az izéfs járt a fejembe, azóta sem ugrik be :D

Esetleg UnionFS, aufs vagy OverlayFS.

Unionfs lesz az szerintem, de teljesen más hangalak jár a fejemben. Kénytelen leszek előkeresni a csomagolóscriptet...

Squashfs!

Egy párszor csináltam vele teljes merevlemezről tükröt, olyanról, amelyről az adott rendszer futott. Boot-oláskor a /tmp partíciót úgy is üríti, a többi ideiglenes cuccot meg újraépíti, kb. annyi hatással sincs a rendszerre, mintha kapna egy áramszünetet (persze adatvesztéstől nem kell tartani).

Ha partíciónként írod ki, akkor meg akár a /tmp és a /home el is hagyható.

Kiírni meg bárhová ki lehet, amit tud kezelni az adott rendszer. Mivel sd kártyán lakik, szerintem a legoptimálisabb kiírni fájlba, aztán azt a fájlt egy másik sd kártyára, tesztnek.

-fs-
Az olyan tárgyakat, amik képesek az mc futtatására, munkaeszköznek nevezzük.

Találtam egy csinos, összefoglaló áttekintést, ( http://szabadszoftver.kormany.hu/letoltesek/keretrendszer/02-Backup_megoldasok.pdf ) de nem találok olyan megoldást ami futó rendszerről csinál mentést, ráadásul bootolható formában. Lehet, hogy Linux alatt nincs ilyen?
--
üdv: virtualm

xfsdump-hoz kifejezetten mountolt partíció kell, szóval, ha xfs-t használsz, szerintem nem gond

amúgy szerintem simán mehet futó környezetről dd. Debian 6 alatt működött :) Persze, ha fut egy mysql server felette, akkor azt külön kell kezelni.

Olvasgatom a man oldalát ( https://linux.die.net/man/8/xfsdump ) de nem látom át a használatának a módját, menetét.

Ugye van egy SD kártyán futó rendszerem, némi segéd programokkal és egy kevés python forrás kóddal. Ezt a rendszert hogyan mentem le az xfsdump programmal, hogy a másik SD kártya is ugyanazt a bootolható állapotot, kernel + x környezet setup + home alatti cuccok legyenek mentve. Baj esetén kártyát cserélek és minden megy tovább ugyanúgy mint előtte.

Jól értelmezem,(?) hogy a megfelelően felparaméterezett xfsdump programmal mentek egy külső eszközre, majd az xfsrestore megfelelő felparaméterezésével pedig megírok egy SD kártyát a mentett állományból. Tesztelés és használata pedig: gép leállítás után SD kártyacsere és ugyanolyan rendszer és környezet kell, hogy működjön a raspberry pin mint a mentés előtt. Ha ez ok, akkor a továbbiakban nincs is szükség a kártyacserékre csak az időközi xfsdump mentésekre és csak baj esetén kell új SD kártyát írni az xfsrestore- al. Ezt az új kártyát előzőleg XFS filesystemre formázni kell valamilyen módon? ( milyen módon ? )
--
üdv: virtualm

raspberry-t még nem installáltam xfs-sel (se) ... ez nehezebb útnak tűnik.
Az alábbi rsync-es megoldást javasolnám helyette. (gondolom ext2 van alatta amúgy)

rsync?
én úgy szoktam, hogy mindig felmountolom a root particiót pl. a /mnt/xxx-be (is) és ezt backupolom, ilyenkor nem kell kínlódni az exclude-okkal. és álltottam is vissza rendszert ilyen backupból...

Köszi, első olvasatra jónak tűnik. Kipróbálom. Megmondom őszintén, hogy a felparaméterezéssel és visszaállítással még nem vagyok tisztában, de szimpatikus, pláne ha jól működik.
--
üdv: virtualm

pl. rsync -avui --delete --numeric-ids --relative --delete-excluded --inplace --timeout=1800 --no-whole-file src dst


--exclude='/proc/' \
--exclude='/dev/' \
--exclude='/var/cache/apt/' \

pont azért írta, hogy felmountolja máshova mégegyszer a root partíciót, hogy ne kelljenek az exclude-ok :)

egyébként nem próbáltam, de az exlude-ok helyett ez nem jobb?
-x, --one-file-system don't cross filesystem boundaries

ezzel az a baj, h pl. ami az eredeti /dev-ben van, azt nem fogja másolni. viszont szükség van rá a bootnál...

A /dev alatti cuccot azt a rendszer hozza létre bootoláskor. Csak az üres mappa mentődik. Ugyanígy van ez a /proc, /sys, és egyéb virtuális fájlrendszeren is. Ezek nincsenek rajta a fájlrendszeren, csak a futó rendszer látja így saját magát.

Ha bebootolsz, és kiírod az sdkártya tartalmát, amiről bootoltál akkor is csak az üres mappák íródnak, a virtuális fájrendszer tartalma nem.

Ami a /dev -ben van, azt az initscriptek, udev, stb... hozzák létre.
A /proc /sys pedig:

mount -t proc none /proc
mount -t sys none /sys

-fs-
Az olyan tárgyakat, amik képesek az mc futtatására, munkaeszköznek nevezzük.

"Nem szeretném a micro SD kártyát kiszedegetni, cserélgetni, hanem alkalomszerűen menteném a kártya tartalmát úgy, hogy egy bootolható, használható rendszert kapjak a mentés végén."

Én alkalomszerűen kiveszem a kártyát, lementem a tartalmát egy image-be és ennyi. Szerintem túlgondolod.

--

"After successfully ignoring Google, FAQ's, the board search and leaving a undecipherable post in the wrong sub-forum don't expect an intelligent reply."

+1, nálam néhány vlan-nak a dhcp-szerverét adja egy régi pi, van rá időablak, amikor megállhat, akkor megy a dd-s dump a kivett kártyáról, egyébként meg a fonrosabb könyvtárakról ha nagyon kell, akkor rsync valahova, bár a releváns konfigokat behúzva git-be az sem kell, csak legfeljebb egy lista az aktuálisan telepített csomagokról (dpkg --get-selections), aztán ennyi.

Mondjuk egy olyan is felmerült bennem, hogy fogod a dd-vel készült image-fájlt egy linuxos gépen, losetup, mount -o rw,loop, és utána az így felcsatolt területre tolod rsync-kel a mentést - bár ebben ugye ott van az a rsync-kel szinkronizálod ay rpi tartalmát. Ebben mondjuk az a kockázat, hogy ha az sd-kártyán sérültté válik/véletlenül törlésre kerül egy fájl, akkor azt is bután átszinkronizálod, amit pont nem kéne.
Viszont van olyan, hogy Borg Backup, ami pont erre (nagy fájlok kis változásainak a mentése) szolgál (deduplikáció) - azzal menteném az image-fájl változásait, minden olyan rsync futtatást követően, amikor történt változás.
https://borgbackup.readthedocs.io/en/stable/index.html

Azaz (a cikus feltételeit finomítani kell a megtartani kívánt full/inkrementális mentések számának megfelelően - friss full backup-hoz goto 1, ha pl. bootmanager csere/frissítés történt):
1. dd-s mentés a kártyáról
2. sdcard.img-ről borgbackup-pal mentés
3. a sdcard.img loopback-mount
4. rsync-kel mentés az rpi-ről a loopback mountolt területre.
5. goto 2.

Így van. Lehet például olyat csinálni, hogy induláskor dd-vel egy tartalék SD-re átkerül minden. Aztán utána már csak azokat a könyvtárakat kell rsync-elni, amelyeknek menet közben változik a tartalma, és szükség lehet rá.

Ha csak simán rsync, akkor nem marad korábbi/előző állapotod, úgyhogy nem vagy előrébb vele :-P

én btrfs-vel és zfs-vel is rsyncelek, így lehet nagyon egyszerűen inkrementális backupot csinálni, ami nagyon diskspace hatékony, mégis megvannak a régi verziók...

És ezt hogyan csinálod?
Készítesz egy btrfs snapshotot, utána azt mountolod és rsync-eled?

Nem jobb egy ilyen script btrfs-en?
https://ownyourbits.com/2018/03/09/easy-sync-of-btrfs-snapshots-with-btrfs-sync/

nem...
a backup szerver backupolja le a device-okat: telefonok, laptopok, masik szerver, külső szerverek, etc. (van amit n óránként, van amit naponta, előtte pingel), a btrfs vagy zfs itt van.

megsnapshotolja a legutolsó snapshot-ot ("verziót"), majd erre rsyncel... ha nem változott semmi, akkor nem fogy a disk space (kivéve a btrfs metadata). persze kezeli a hourly, daily, monthly, yearly snapshotokat...

a btrfs-sync szkript az csak összesynceli a source-on lévő btrfs snapshotokat. elvileg gyorsabb a dolog, de ugye mindkét helyen btrfs kell legyen...

rdiff-backup :)

+1

Ja igen, 3+, akkor tud PXE bootot kártya nélkül. Case solved :)
--

"After successfully ignoring Google, FAQ's, the board search and leaving a undecipherable post in the wrong sub-forum don't expect an intelligent reply."

Hacsak úgy nem... :D

Köszönöm a javaslatokat, végig veszem őket. Egyenlőre a dd működött, de macerás a kártya kivesz berak pláne ha majd egy összeszerelt, dobozolt készülékről lesz szó. Ezt a dd módszert kell majd kombinálni valamivel, kiegészíteni valami jól scriptelhető módon. ( amúgy meg a python forrás munkák azok mennek a repoba. )
--
üdv: virtualm

A dd az valóban egyeNlőre hozza ki a mentett SD-kártyát és a mentést, gondolom a szó, amit kerestél, az az egyelőre volt...

Lehet, hogy félre érthető volt az "egyenlőre" kifejezés? Igaz, a "pillanatnyilag" szót is használhattam volna helyette. Az új nyelvtani szabályok, mint ez is, nekem nem tetszenek, nem áll rá a nyelvem.
--
üdv: virtualm

Mihez képest új ez a szabály? 1984 előtt elfogadott volt az "egyenlőre" alak ebben az értelemben?
(Komolyan kérdezem, nem néztem utána.)

Nekem, 65 éves vén hülyének új.
--
üdv: virtualm

Egyenlőre : (ugyan akkora) egyenelő darabokra vágtam a spárgát.
Egyelőre : (most még) egyelőre megfelel ez a nadrág.
Szerintem a Nagy háború előtt is erre okították a nebulókat az oskolában. :)
De nem néztem utána!

Pedig van vonatkozó bash is hozzá: http://bash.hu/14617

+1

A nyelvészet mellett azért na, nem ártana azt is figyelembe venni hogy a pi nem használja az mbr-t, csak rá kell másolni a fájlokat az sd kártyára és jónapot. A mentés is kb. annyi hogy le kell másolni. Azaz nem a dd a kérdés, hanem hogy mi lesz a nyitott/írás alatti fájlokkal.

A móka akkor van, ha squashfs van a masinán, de ha jól láttam az nincs.

Kombinálni nem nagyon lehet. dd az kell a bootolhatóság miatt, és a kártyát is ki kell venni, mert nem futhat róla rendszer dd-zés közben.

A sima rsync is jó mentést csinál, de az nem lesz bootképes.

Ha csak úgy nem érted a vegyítést, hogy először csinálsz egy alap dd-s mentést legelőször (kártyát kivéve), majd rendszeres időközönként rsync-eset (ehhez nem kell kivenni a kártyát), és ha vissza akarod húzni a rendszert, akkor először a dd-s lemezképet húzod vissza (kártya kivesz), majd az rsynceset.


No keyboard detected... Press F1 to run the SETUP

Biztos kell a dd a bootolhatóság miatt? Most már tényleg ki kell próbálnom, de nem rémlik ilyen.

Nem kell a dd.
A boot partíció legyen a helyén a megfelelő fájlrendszerrel (FAT) és tartalommal, ezen felül sima fájlszintű másolás működik.

Szerintem is, de este most már teszek egy próbát.

Szóval valószínűleg az összes ilyen dédés szenvedés redukálható a "hogyan másoljunk át fájlokat" problémáig.

Igen.

Amúgy általánosságban is, csak jobban kell figyelni a betöltőre. :-)
Kevés helyzet van, amikor az eszközön belüli pontos "pozíció" számít.

Szia,

En pi-re f2fs-t hasznalok es rsync-el mentek halozaton keresztul nas-ra. Szerintem erdemes kiprobalni mindkettot :
http://whitehorseplanet.org/gate/topics/documentation/public/howto_ext4_to_f2fs_root_partition_raspi.html

Koszi,
Gergo

Megéri ez a macera? E nélkül mennyit bírnak a mai SD kártyák? Ezzel mennyivel lesz hosszabb az élettartama?

Tényleg, melyik gyártó kártyái a jónak mondhatóak?
Egy Samsung SD 16GB Class10, egy percet sem ment, a formázásba belebukott.
--
üdv: virtualm

Szerintem SD kártyára mindenképp megéri az f2fs. Kíméli az élettartamát. SSD-nél mindegy, ott bármilyen fájlrendszer használható, nem kell kímélgetni a közhiedelemmel ellentétben. De pendrive-ot, SD kártyát, ilyesmit érdemes f2fs-sel, noatime-mal, stb-vel használni, azoknál minden csepp írásspórolás számíthat. Persze attól is függ, hogy mire van használva, ha valami embedded feladat, aminél csak bebootol a rendszer az SD kártyáról, de nem nagyon írogat rá, annál mindegy. De ha intenzíven van benne használva a kártya, akkor érdemes bevállalni a macerát.


No keyboard detected... Press F1 to run the SETUP

És mennyivel jobban tudna működni f2fs, ha nem kellene mindent feltételeznie az FTL-ről, hanem mondjuk a controller közölné az adatokat.

Igen, ezért írom, hogy SSD-n nem kell, mert ott van aktív vezérlő, ami ilyen FTL-ről külön gondoskodik, meg ügyel a cellák egyenletes fárasztására, csinál garbage collectiont. De pendrive-oknál, SD kártyáknál nincs ilyen, azok emiatt sokkal kisebb írásterhelhetőséggel bírnak.


No keyboard detected... Press F1 to run the SETUP

Én úgy tudom, hogy mindkettőnél van FTL: (Micro)SD kártyáknál és pendrive-oknál is.
Talán a SmartMedia kártya volt az utolsó consumer flash alapú adathordozó, amin nem volt.

FTL az lehet, hogy van, de rendes aktív vezérlő, ami gondoskodni tudna a Flash cellák egyenletes fárasztásáról, olyan biztosan nincs SD kártyákon, pendrive-okon sem. Tapasztalatból mondom, hogy ezek tényleg sokkal kevesebb írást bírnak, főleg akkor finganak ki nagyon gyorsan, ha OS fut róluk, ami rendszeresen írogat sok fájlt. Valami hihetetlenül gyorsan ki tudnak fingani. Adattárolásra lettek ezek kitalálva, nem rendszer futtatására.


No keyboard detected... Press F1 to run the SETUP

Szamodra mit jelent az "aktiv" vezerlo? Milyen egy "passziv" vezerlo?

Tudomasom szerint van wear leveling, csak kisebb a tartalek terulet es gyengebb minoseguek a cellak, igy van hogy csak 250-1000 irasi ciklust tudnak. Tovabba gyakoribb a nem vart tapelvetel (+ESD), ami szinten gyakran okozza a pendrive halalat.

Azt értem aktív vezérlőn, ami önálló hatáskörben molyol a cellákon, adatokat helyez át közöttük, szemetet takarít, hogy egyenletesen fáradjanak a cellák. Tudtommal nem csak a NAND más, hanem a pendirve-SD kártyán csak valami passzív, bedrótozott logikájú IC randomizálja valamennyire az írásokat, de ilyen belső adatmenedzselő hatáskörrel nem bír. Így pl. egy pendrive-on nem csak azért 10000× kevesebb az írásterhelhetőség, mert a Flash-memória kevesebbet bír (azért is, de ebben még csak olyan 100-500×-os lenne a különbség), hanem ezek a egyenletes adatelosztási trükközés. Pl. ha egy 32 gigás pendrive-ra vagy SD kártyára felteszel 16 GB állandóan tárolt adatot, és emellett irkálsz rá újabb 10-16 GB-ot, akkor csak a Flash-memória fele fog fáradni, azok a cellák, amikben az állandó adat van, nem fognak kopni, míg a meghajtó többi részén meg többszörös terhelésnek lesz kitéve, így meg sokkal gyorsabban adja be a kulcsot.

Nem véletlen eszik egy SSD 6-7 W-ot, meg melegszik fel 50-70 fokra, míg az ilyen SD kártyák mW-ban mérhetőek. Attól még hogy Flash-memóriába dolgoznak, számottevő működésben is a különbség.


No keyboard detected... Press F1 to run the SETUP

Na csak megnéztem:
https://ts.data61.csiro.au/publications/nicta_slides/8311.pdf

Nincs bedrótozott logika, 8051/ARM MCU-k vannak bennük és van wear leveling. Ráadásul újabb kártyák akár 1-2.88 W teljesítményűek.
Az említett NILFS2 is érdekes. És most beugrott, hogy még régi eMMC-k is használtak wear levelinget, ami néhány chip verzióban bugosra sikeredett és SDS lett az eredménye:
https://undocumented.software/wiki_dump/EMMC_Bugs.html

15-20 perc alatt megvan, es amig korabban fel evente doglottek az sd kartyaim, addig most tobb mint 1 even futnak. 3db pi-m van, nekem inkabb megeri ennyit raszanni, mint cserelgetni a katyakat. A backup mar csak megszokasbol megy. Elobb volt nalam backup mint f2fs.

Koszi,
Gergo

Több mint egy év, mire cserélni kell őket vagy több mint egy éve fut mindegyik ezidáig gond nélkül?

Több mint egy éve fut mindegyik ezidáig gond nélkül.

Koszi,
Gergo

Köszi.
Össze fogok rakni egy rendszert, amihez gondoltam, hogy többek között ezt a megoldást is használom, eszerint tapasztalat alapján is érdemes.

Sub. Nagyon. :)
Köszi

Nem jobb megoldas, hogyha mentesz egy kiindulasi rendszert (akar raspbian adott verziojat), es utana vagy erre kitalalt programmal (pl ansible), vagy egy shell scripttel
felepited a rendszert?

A backup pedig celiranyosan azok a fajlok, amik keletkeznek. Pl. egy sqlite fajl.

Azt, hogy mit miert installaltal, mar egy honap mulva elfelejted. Amikor uj verziot kell kiadni, 2 het csak azzal fog eltelni, hogy a kornyezetet ujraepitsd, mert "egyszer mar mukodott".

---
Saying a programming language is good because it works on all platforms is like saying anal sex is good because it works on all genders....

a futás közbeni dd-vel problémák lehetnek, mert mentés közben is változhatnak fájlok, ami inkonzisztenciát okoz.

Van okosabb megoldás, amikor egy image fájlt hozunk létre és abba szinkronizáljuk a fájlokat. Másik előnye, hogy bár dd-vel kiírható képet csinál, de csak akkora lesz a mentés, mint az adat, nem pedig akkora, mint az sd kártya mérete

https://prohardver.hu/tema/raspberry_pi/hsz_29897-29897.html

Ez lesz a nyerő, több oknál fogva is, ugyanis a 32GB kártya csak 29GB- ot enged használni.

Érdekes, hogy Ők az eredeti cikkben azt írják, hogy a script a pín fut, ott csinálja meg a csökkentett méretű image fájlt, amit elmenthetsz, majd új és kisebb kártyára ki is irhatod. A bootoláskor a mentéskori állapotokkal indul. Ez jól hangzik, kipróbálom.
--
üdv: virtualm

sub

A dd- vel sikerült a mentésem. A 32GB- os kártya 3/4- e üres. A tartalék 32GB- os kártyára nem tudtam visszaírni a képfájlt mert kevés a hely üzit kaptam. Teljesen leürítettem, formáztam, igaz előtte el kellett távolítanom a több kisebb partíciót és végül 29GB- nak formázódott a cucc és így keveselte a dd.

Ti mivel formáztok és hogyan nyerhetem vissza a 32GB- os méretet?
Hogyan kellene úgy menteni, hogy csak az aktív foglalt méretre legyen szükség?
Hiába van egy csomó szabad hely az új kártyán, mégis kevesli a kártya méretet.
--
üdv: virtualm

Tulajdonképpen valami hasonló megoldást szeretnél szerintem, mint, amit azbest is írt fent.
Nem feltétlen a konkrét scripttel (nem tudom, pl. az fdisk működése mennyire változik a későbbiekben), de ez működőképes dolog.
Visszaállítás után pedig az új kártyán "kiterjeszthető" a partíció a kártya pontos méretére.

Ehhez gyakorlatilag létre kell hozni egy fájlt a szükséges méretben.
Ez felcsatolható loop eszközként (gyakorlatilag mintha ez lenne az SD-kártya), azon belül létrehozható a két partíció, a megfelelő fájlrendszer, ezt követően pedig mehetnek rá az adatok.
Lényegében a fenti megoldás is ezt csinálja.

Köszönöm, most tényleg ez kell mert a kártyám kisebbnek mutatja magát mint valójában. ( 32GB helyett )

fdisk /dev/sdc

Unpartitioned space /dev/sdc: 29,7 GiB, 31913917952 bytes, 62331871 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes

Start End Sectors Size
2048 62333918 62331871 29,7G

Nem találom a módját, hogy miként tudom a teljes kártya méretet használni.

--
üdv: virtualm

Gyakorlatilag létrehozol rajta két partíciót a boot + rendszer adatainak és átmásolod rájuk a fájlokat.

...vagy a fent írt módon előkészített image-et kiírod és a fájlrendszer típusa által támogatott módon megcsinálod, hogy a lemez végéig érjen (a pontos metódus eltérhet).

Esetleg gparted-ben grafikus felületen is össze lehet kattintgatni, egyúttal a partíció pontos mérete is beállítható.

Hint: tessék alaposan megnézni a két prefixet: a kártya csomagolásán a méreténél "G", azaz 10^9, az fdisknél viszont "Gi", ami 2^30. A 32GB-hoz képest hiányzó 86082048 (0.269%) bájt az a gyártástechnológia okán hiányzik.

Köszönöm az információkat és a segítséget.
--
üdv: virtualm

Most utólag próbálkoztam az alapos megtekintéssel, de nem volt sikeres. Ime a látható SD kártya képek:
https://i.imgur.com/J4hPiUW.png
https://i.imgur.com/hfxiOM6.png
https://i.imgur.com/foTnbfY.png
https://i.imgur.com/smI1uoc.png
https://i.imgur.com/2SCOxUi.png
Ezen a hivatalos Rpi SD kártyán és a csomagoláson nem találtam az említett G- Gi adatokat.
--
üdv: virtualm

Ez az egész emlékeim szerint valahol ott kezdődött, amikor elkezdték az 5-600MB-os merevlemezeket tíz hatványaival marketingelni.
Így lett a ~640 MB-os merevlemezem 610 MB körüli.

Ekkortájt volt persze az is, hogy okosoknak szemet szúrt az, hogy az SI-prefixek szerint a kilo 1000 (10^3), mega 10^6, stb, míg informatikában a bináris számrendszerből következően a kilo 1024 (2^10), a mega pedig 2^20, stb... prefixeket használták.
Gondolták, hogy "egységesítik" a dolgot, így nincs belőle félreértés... a kilo legyen mindig 1000, ellenben informatikában használják a "kibi"-t, ami 1024, stb... így lett belőle kibibájt, ami persze megosztotta az embereket.

Szumma szummárum, azóta kétféle jelölés létezik... a hagyományos, és az új, ez pedig félreértéseket és kavarodásokat tud okozni.

Így marketing anyagokban GB-ot használnak tíz hatványaival, szakmai környezetben pedig odabiggyesztik a kis i-t a bináris leképezéshez (ld. GiB), ha korrektek akarnak lenni; minden más esetben gigabájtokról beszélnek és sok esetben kettő hatványait értik alatta...

Visszatérve a memóriakártyákra, ott a marketing szöveg 32GB-ot mond, ami alatt kb. 32000000000 byte-ot ért.
A program viszont kb. 29.8 GiB-ot lát ugyanebből, mert ő a konkrét, bináris adatokkal dolgozik, kettes számrendszerben reprezentálva a fentit

Persze ő sem lát pontosan 29.8 Gib-ot, mert ő a konkrét adatokkal dolgozik, ami ennél kevesebb (ezért volt fent a kb.) - pl. lehetnek hibás cellák a flash-ben, amit a vezérlő elfed, ill. egyéb terület is, ami nem közvetlen a hasznos adatterülethez tartozik...

Ez a hosszú magyarázat a fentire. :)

Köszönöm a hasznos információkat.

Még azt kéne tudni, hogyan lehet a particionálásba, formattálásba bevonni az első 4MB nem használt területet, mert úgy tűnik, hogy ennek a hiánya miatt nem sikerült a dd- vel mentett 32GB- os kártyát, 32GB- osra átírni a hely hiány miatt. A hely takarékos mentés és visszaállítás ugyan megoldódott a remek kis scripttel, de nem akarok hülyén meghalni. Nem gondolnám, hogy pont az első 4MB hibás, illetve lehet, mert nem tudom megvizsgálni, hogy valóban az e vagy én bénázok valamit a particionálással, hogy az ott marad parlagon.

Linux alatt van olyan alacsonyszintű formattáló program ami megmutatja a rossz területeket?
--
üdv: virtualm

Veszel két, azonos tipusú, azonos sorozatban készült kártyát, ez az egyik lehetőség, a másik, hogy addig keresgélsz, amig ugyanakkora vagy nagyobb nyers méretű 32GB-os kártyát találsz.
Sajnos a dd-s mentés csak legalább ugyanakkora médiára pakolható vissza (oké, fájlrendszertől függ, mert van, aminek lecsatolva csökkenthető a mérete, de ez erősen átgondolós játék egy dd-vel kreált image esetén, hiszen első körben a losetup-ot kell ügyesen használni :-))

"Még azt kéne tudni, hogyan lehet a particionálásba, formattálásba bevonni az első 4MB nem használt területet,"
Előveszel egy tíz évvel ezelőtti linukszot, és azzal particionálsz. Komolyan. Az még nem lacafacázik.

Ha a dd-vel a teljes eszközt olvasod / írod (sda / sdb, stb), akkor mindent másol - a partíciós táblát, a partíciókat, az adatokat, még az "üres helyet" is.

Lemásolni valószínűleg azért nem tudtad, mert a két SD-kártya eltér - éppen úgy, hogy a korábbi kártyád nagyobb kapacitású, mint, amire át szeretted volna másolni. Az eltérés valószínűleg nem nagy (néhány tíz MB talán vagy akár még annyi sem), de éppen elég ahhoz, hogy "túllógjon" a kártyán.
Kapacitásbeli eltérések egyébként nem csak uSD kártyák között lehetnek, egyes gyártók HDD-i között is volt.

Ha mindenképpen dd-vel szeretnél teljes lemezt klónozni, megteheted, hogy úgy készíted el a 32GB-os kártyádat, hogy a partíciót 100-200MB-tal rövidebbre veszed, és az image-et csak eddig a pontig olvasod be. Így beleférsz más kártyának a méretkorlátjába is, vagy az eredeti, teljes image-et kiírva az új eszközre a hibajelzés ellenére működni fog (amennyiben előbb befejeződik a partíció mint az új kártya fizikai vége).

...hogy miért pont 4MB-ot hagy ki a lemez elején, azt nem tudom pontosan, de oka van.
Annak idején az MBR a merevlemez első 512 byte-ját foglalta el (első szektorát), itt helyezkedik el a partíciós tábla és a rendszerbetöltő.
Később az egyes rendszerbetöltők az MBR és az első partíció közötti területre tették magukat, így pl. a GRUB egy része is itt van, ha "MBR-be telepítik".
Feltételezem, emiatt hoz létre a particionáló program egy 4MB-os fenntartott területet az első partíció elé.

Egyébként van olyan eset is, amikor nem kerül partíciós tábla az eszközre (pendrive, uSD), hanem rögtön a fájlrendszer kerül rá.
Mostanában már nem jellemző, de régebben láttam több, ilyen módon létrehozott pendrive-ot is.

Nem valószínű, hogy találsz olyan programot, ami a uSD kártya esetleges hibás részeit megmutatja.
Ha van is ilyen, az gyártói program, vagy legalábbis gyártóspecifikus.
Egyes SSD-khez vagy pendrive-okhoz létezik olyan program, amivel újra lehet inicializálni, így egy esetlegesen nem működő eszköz visszahozható az életbe - de ezek nem hivatalosan kiadott programok és csak egyes vezérlőkkel működnek, vagyis nem nagy az esély rá, hogy, ha ilyennel találkozik is az ember, a programot is felleli a megoldáshoz...

Nekem, most volt az "aha" efektus.
Nem akarok minden áron dd- vel ügyködni, de zavart az értetlenség. Köszönöm a többoldalú magyarázatot. Különben is, az asszony már rám szólt, hogy mit vacakolok még mindig ezzel ha már működik a mentésem.
--
üdv: virtualm

Szívesen. :)

Annyi kiegészítés még a fentihez, hogy az MBR-ben lévő kód ugrik elvileg a boot sector-ra, de, mivel az újabb boot manager-eknek ennél (1. sector) nagyobb hely kell, ezért ez ugrik pl. a Grub kódjára, ami lehet az első partíció előtt még (vagy a partíció elején), és ez végzi a tényleges rendszerbetöltést.
Ez viszont megadja a lehetőséget arra, hogy akár teljesen eltérő operációs rendszereket töltsön be.

Ha jól emlékszem, a Windows NT-től a Windows betöltője sem 512 byte-os volt, hanem talán 2048 vagy 4096, de egy ideje a valós szektorméret is ennyi...

...aztán van még a GPT. :-)

nemide

Plusz kis adalék:
a kártyáknál és pendriveknél lehetnek különbségek a GB és GiB mértékegységek körüli kavarás nélkül is.

Egyszerűen arról van szó, hogy sok más területhez hasonlóan, itt is vannak hibás területek (ahogy te is írtad). Ezt a gyárban az adott példány minőségének megfelelően állítják be valamelyik méretre a termékpaletta változatai szerint. Lehet, hogy 32GB-os flash chip van a 8GB-os kártyában is, csak nagyon sok volt a hibás terület rajta, ezért a 8-as volt a legelső méret lefelé haladva, amit teljesíteni tudott.

Namost, ha a 8 az valójában csak 7.9, míg a 16 valójában 15.8, akkor több példány fogja teljesíteni a nagyobb méretű besorolást. Jobb lesz a kihozatal és magasabb áron tudják eladni, mintha tényleg a névleges értékre lövik be. A márkásabb gyártók drágább kártyáinál, pendriveinél általában komolyabban veszik a méretezést, szigorúbb feltételeket írnak elő vagy akár a termékinfónál fel is tüntetik azt. Az olcsóbb és noname-ebb eszközöknél pedig jellemzően kicsit alá lőnek, ezért pár száz megával is kisebbek lehetnek. Ezért nem jön ki sehogy a matek némelyik kártyánál :)

De ugyanannak a gyártónak a különböző modeljei közt is lehet különbség aszerint, hogy hogyan pozicionálják az árazást és kihozatalt. Viszont azonos sorozatból való példányoknál jellemezően pontosan azonos a kapacitás is.

A kétféle mértékegység rendszer közti kavarással meg jól jártak a gyártók, mert a binárisan gyártható és SI szerint megadott méret különbségébe beleférhet a firmware helye, tartalék szektorok és némi ráhagyás a kihozatal biztosításához :)

azbeszt és VaZso barátunk találta meg nekem azt a scripttet amivel az élő futó rendszert image fájlba írtam, majd másik linuxos gépre is lementettem, majd ott a kisebb méretű kártyára dd- vel kiírtam, ami ugyan nem lett bootolható, de már lett egy jó mentésem. Ezután az SD copier nevű linuxos alkalmazással az előzőleg mentett fájlt copiztam az új kisebb méretűre, teljes sikerrel. Ez bootolható és mindenem megmaradt ami volt az előző rendszeren.

Az eredeti és az új SD mentett SD kártyák particioi igy néznek ki:
origin : https://i.imgur.com/8TyWSfd.png
mentett : https://i.imgur.com/tJnHYX4.png

Az új kártyán hiába csináltam meg a f2fs fájlredszert, az SD copier felülírta és az eredetit leutánozta, pedig jó lenne átállni majd erre.

Ez a mentő script : https://pastebin.com/URtidbmc jó és gyorsan lefut. Kicsit kéne rajta thuningolni, például, hogy távolra mentsen és dátumidő legyen a fájlnévben és akkor nem írja felül a régi mentést. Na de nem lehet minden tökéletes, ez így is jól használható.

Van még néhány dolog amit ki fogok próbálni, de most "hirtelen" ennyi elég. Köszönöm mindenkinek az aktív segítségét.
--
üdv: virtualm

Dátum-időhoz cseréld az imagefile sort erre:
IMAGEFILE="$WORKDIR/RASPBERRY_PI_SHRINKED_IMAGE"`date "+%Y%b%e-%H:%M":%S`".IMG"

A post első felében, baloghge barátunk megemlítette, hogy f2fs- t használ. Utána olvasva ez egy nagyon jó dolog és szeretném a mentésem scriptjében alkalmazni a lényegét. A jól működő mentésem eredeti mentő scriptje : https://pastebin.com/URtidbmc 162. sorától van rá lehetőség mert ott úgy látom, hogy a mentés helyének a fájl rendszerét hozza létre.

A kérdésem az, hogy itt szabad e, helyes e az mkfs.vfat -F 32 -I $LOOPDEVICE'p1'
és mkfs.ext4 $LOOPDEVICE'p2' helyett f2fs alkalmazása ?
Tehát az mkfs helyes felparaméterezése a lényegi kérdés, vagy más módon kell létrehozni az új helyen a 2fs fájl systemet?

A boot sector maradhat vfat ? mkfs.vfat -F 32 -I $LOOPDEVICE'p1'
A gyakran irogatott home terület pedig mkfs.f2fs $LOOPDEVICE'p2' re módosulhat és akkor megússzhatjuk a macerás fájl rendszer cserét, mert az itt ugye most megtörtént. http://whitehorseplanet.org/gate/topics/documentation/public/howto_ext4_to_f2fs_root_partition_raspi.html amit

A visszaállítás, kártyára írás ugye a dd- vel történik. Az akkor ott az f2fs fájl rendszert fogja visszaállítani?
Egy életem- egy halálom ezt holnap kipróbálom.

--
üdv: virtualm

A boot partíció csak FAT lehet, más fájlrendszerről nem fog elindulni.
Ezzel alapvetően nincs gond, normál körülmények között nem módosul, nem írogatja a rendszer.

Az, hogy f2fs-ként hozod létre a fájlrendszert, egy dolog, de ezt az op.rendszernek is meg kell mondani.
Most nincs előttem PI, de a boot partíción van talán egy config.txt (cmdline.txt?), itt biztosan át kell állítani a fájlrendszer típusát.
A /etc/fstab-ban is biztos, hogy át kell írnod a típust.
...és reménykedni, hogy a kernel ismeri ezt a fájlrendszert. :)

Ha a kernel nem ismeri, akkor ezt is bele kell fordítani, esetleg keresni egy alternatív kernelt, amiben benne van...

ok, holnap megnézem, átírom kipróbálom, most már bátran mert van mentésem.

( Egy mentés az nem mentés, két mentés az fél mentés, a három mentés az egy mentés.)
--
üdv: virtualm