rsynca hela Raspberryn som backup. Frågor.

Permalänk
Medlem

rsynca hela Raspberryn som backup. Frågor.

Behöver ett klargörande/bekräftelse och några svar. Har en RPI4 med egengjorda applikationer och script/confs. Beroende på projektets mål ändras script, conf samt applikationen något. Jag vill inte hela tiden spara varje proj som en image. Tänkte att jag skulle testa rsync som backupmetod och provar enligt följande procedur:

Jag kör på en RPI4 med Buster (ej noobs) som jag vill ta backup på/clona.
Satte in ett SD-kort, target med samma partitioner och formateringar som source i en adapter i ett av USB-uttagen.
Monterade tomma SD-kortets /root partition till /mnt/s/
Rsyncade root från min source (den RPI4 jag kör på) till /mnt/s/
Gjorde en umount
Monterade nu tomma SD-kortets /boot partition till /mnt/s
Rsyncade min /source/boot/ till /mnt/s/
Gjorde en umount

Testade. Funkade.

Fråga #1: Det som ligger under /boot, är det samma filer som ligger på partitionen /boot?
Fråga #2: Om #1 är jakande så kan jag göra en rsync till en ex.vis minnessticka formaterad med ext4 och på så sätt spara projektet?
Fråga #3: Om alla frågor ovan leder till ett ja, kan jag göra en compress på samma gång när jag rsyncar så jag får allt i en "zip"?

Var finns det fallgropar?

Tacksam för svar.

Permalänk
Medlem

Filerna som ligger under /boot/ på rootfilsystemet har sannolikt inte uppdaterats sedan installationen eftersom boot-partitionen alltid är monterad där, dvs bootloader, firmware, kärnan och config.txt mm..

Permalänk
Medlem
Skrivet av FattarNiInte:

Filerna som ligger under /boot/ på rootfilsystemet har sannolikt inte uppdaterats sedan installationen eftersom boot-partitionen alltid är monterad där, dvs bootloader, firmware, kärnan och config.txt mm..

Med risk för dum fråga men jag är inte fullt insatt i hur en installation går till men kopieras mappen /boot till boot-partitionen vid installationen? Senare blir dessa två platser i osync beroende på uppdateringar?
I sådana fall ska jag ju rsynca partitionen /boot istället för mappen /boot.

Permalänk
Medlem

@Sweedland, ungefär så men tror alldrig /boot/ på rootfilsystemet rörs. Installation? Du skrev väl en färdig "image" till SD-kortet?
Jag vet inte varför det överhuvudtaget finns filer i /boot/ på rootfilsystemet men det var så för mig också. Verkar som om "image"-filerna kan innehålla dubbel uppsättning av /boot/*.
Jag kör Manjaro-arm(-ish), typ.
Du kan kolla om filerna är lika eller skiljer i dina båda /boot med tex diff.

Permalänk
Medlem
Skrivet av FattarNiInte:

@Sweedland, ungefär så men tror alldrig /boot/ på rootfilsystemet rörs. Installation? Du skrev väl en färdig "image" till SD-kortet?
Jag vet inte varför det överhuvudtaget finns filer i /boot/ på rootfilsystemet men det var så för mig också. Verkar som om "image"-filerna kan innehålla dubbel uppsättning av /boot/*.
Jag kör Manjaro-arm(-ish), typ.
Du kan kolla om filerna är lika eller skiljer i dina båda /boot med tex diff.

"Target" var en annan Buster jag rensade /root partitionen på men behöll dess /boot. Sen clonade jag över source-root och provade. Men mus o tangentbord funkade inte. Provade olika sätt att få det att funka men icke. Googlade och läste nåt om att "kernel" kanske inte stämmer mot "modulerna" och då tänkte jag att jag kanske skulle föra över /boot också. Det var då jag tänkte att /boot mappen på source kunde rsyncas över. Så gjorde jag o då funkade det.
Så mitt inlägg här var egentligen att få bekräftat att man kunde göra så men att det ev. kan finnas vissa skillnader eftersom /boot partitionen kan ha fått en uppdatering (update/upgrade) men inte /boot-mappen.
Jag ska göra en diff på boot partition och /boot-mappen på en random Buster jag har....nyfiken,.

PS/ Undra om man kan döpa om /boot mappen och göra ett test....om der går och RPI:n startar ändå anv. ju inte /boot-mappen. /DS

Permalänk
Medlem

Du kan döpa om /boot-mappen och skapa en ny /boot-map.
Boot mappen måste nog finnas där för att boot-partitionen skall månteras på den.

Permalänk
Medlem
Skrivet av FattarNiInte:

Du kan döpa om /boot-mappen och skapa en ny /boot-map.
Boot mappen måste nog finnas där för att boot-partitionen skall månteras på den.

Men om det är så, så finns det bara EN uppsättning boot per SD-kort. Samma filer på partitionen BOOT som mappen /boot. Då kan man rsynca mappen /boot. Jag får inte ihop det med din första kommentar...
Om det är så att partitionen /boot återspeglas i mappen boot så räcker det med att ta en rsync på hela / och då får man med /boot också. Så när man ska clona ett kort så rsyncar man "allt" till targets root och mappen /boot till boot-partitionen. Hängde du med?

Permalänk
Medlem

Ett SD-kort monterat i adapter har en /boot mapp men inga filer finns i den mappen. Därför ska en backup med rsync ske med ett SD-kort som används för då finns /boot partitionen återspeglad under /boot.

Permalänk
Medlem

Oavsett om du tar backup eller inte så kan det ju vara bra att ta en titt på riktig källkodshantering med till exempel git. Det är ofta bra att ha kvar gamla versioner som referens. Även versionshantering av nödvändiga konfigurationsändringar går att lösa med lite fantasi.

Permalänk
Medlem
Skrivet av KAD:

Oavsett om du tar backup eller inte så kan det ju vara bra att ta en titt på riktig källkodshantering med till exempel git. Det är ofta bra att ha kvar gamla versioner som referens. Även versionshantering av nödvändiga konfigurationsändringar går att lösa med lite fantasi.

Precis. Jag använder git normalt sett när applikationer skrivs. Att spara hela RPIn är mer att det känns "tryggt". Kör man en update/upgrade så händer en hel del och då vill jag gärna spara rubbet.

Permalänk
Medlem

Just filerna i /boot är svårflyttade som filer för att dessa är inbördes låsta till varandra på LBA-nivå mha initrd.img eller motsvarande och varje flytt/ändring där gör att man måste köra update med update-initramfs eller motsvarande.

Det beror på att Uboot/bios och bootloader som grub är rätt dumma och förstår inte filsystem och därför behöver förprocessade listor med absolutadresserade LBA-nummer av sektorer som den skall laddas in och en hint var början är, innan kärnan kan startas och som har betydligt mer kunskap om filsystem än vad bootloadern har.

så editerar man filer eller kopiera runt filer och tar bort de gamla filerna i /boot så stämmer inte LBA-listorna längre och det måste processas om igen om det skall bara bootbart igen.

---

Vill man hantera versioner av hela sd-diskimage så kan man packa i deduplicerande arkiv som borg-backup eller restic där sektor med samma innehåll bara finns en enda gång i arkivet oavsett hur många diskimages man lägger i arkivet. detta kan spara väldigt mycket plats.

Permalänk
Medlem

Min favorit för ändamålet är fsarchiver (finns i Rasbian repo)...

https://www.fsarchiver.org

Har använt det i flera år för att ta images på SD korten i mina Rpi's och vid behov återställt dem.

Permalänk
Medlem
Skrivet av xxargs:

Just filerna i /boot är svårflyttade som filer för att dessa är inbördes låsta till varandra på LBA-nivå mha initrd.img eller motsvarande och varje flytt/ändring där gör att man måste köra update med update-initramfs eller motsvarande.

Det beror på att Uboot/bios och bootloader som grub är rätt dumma och förstår inte filsystem och därför behöver förprocessade listor med absolutadresserade LBA-nummer av sektorer som den skall laddas in och en hint var början är, innan kärnan kan startas och som har betydligt mer kunskap om filsystem än vad bootloadern har.

så editerar man filer eller kopiera runt filer och tar bort de gamla filerna i /boot så stämmer inte LBA-listorna längre och det måste processas om igen om det skall bara bootbart igen.

---

Vill man hantera versioner av hela sd-diskimage så kan man packa i deduplicerande arkiv som borg-backup eller restic där sektor med samma innehåll bara finns en enda gång i arkivet oavsett hur många diskimages man lägger i arkivet. detta kan spara väldigt mycket plats.

Ok. Viktig information. Det går dock att komma runt om man kör update-initramfs?
Borg har jag använt tidigare ytligt. restic ska jag googla på.
Räkna med frågor från mig. Tack för tipsen.

Permalänk
Medlem
Skrivet av xxargs:

Just filerna i /boot är svårflyttade som filer för att dessa är inbördes låsta till varandra på LBA-nivå mha initrd.img eller motsvarande och varje flytt/ändring där gör att man måste köra update med update-initramfs eller motsvarande.

Det beror på att Uboot/bios och bootloader som grub är rätt dumma och förstår inte filsystem och därför behöver förprocessade listor med absolutadresserade LBA-nummer av sektorer som den skall laddas in och en hint var början är, innan kärnan kan startas och som har betydligt mer kunskap om filsystem än vad bootloadern har.

så editerar man filer eller kopiera runt filer och tar bort de gamla filerna i /boot så stämmer inte LBA-listorna längre och det måste processas om igen om det skall bara bootbart igen.

---

Vill man hantera versioner av hela sd-diskimage så kan man packa i deduplicerande arkiv som borg-backup eller restic där sektor med samma innehåll bara finns en enda gång i arkivet oavsett hur många diskimages man lägger i arkivet. detta kan spara väldigt mycket plats.

Jag har läst en hel del om att ta rsync alt borg backup (ej img) på /boot och /root och en del avråder.
Jag jobbar så att beroende på rpi-utgåva ändrar jag vissa conf filer och kanske installerar nån annan mail-client och ibland har jag rpi:n som hotspot, ibland inte. Sen även en annan applikation. Detta är svårt att notera, alla ändringar en viss utgåva kommer att ha. Därför tänkte jag ta rsync-backup på /boot & /root men nu avråder vissa det.
En annan lösning kan vara att ha en image med tom /root partition men färdig och klar /boot partition? Sen kör jag rsync tillbaka till den tomma /root partitionen. Då får jag ju med alla ändrade confs och även en annan mail-klient om just den utgåvan hade det. Kan detta vara en lösning för mig? Alltså, ha en image med tom /root partition men körklar /boot som jag lägger på ett tomt SD-kort och sen påför med rsync den utgåva jag vill ha.
Jag vill ju gärna ha backuppen i en fil och komprimerad och då kanske borg är ett alternativ istf rsync.