Cum ar trebui să fie redundantă partiția EFI System fără a utiliza RAID hardware?

Ce este BCP pentru a face redundantă partiția EFI System fără a utiliza RAID hardware?

Dacă creez partiții de sistem EFI de 3x pe dispozitive diferite și apoi creez o copie de rezervă a oricăror modificări făcute în sistemul principal (montat la /boot/efi) la dispozitivele de rezervă (montate la /boot/efi-[bc]):

• Va porni sistemul în continuare dacă dispozitivul principal eșuează, adică va selecta una dintre partițiile de sistem EFI de rezervă?
• Va selecta sistemul o partiție de sistem EFI în mod determinist atunci când pornește, adică trebuie să fie replicate modificările aduse celei principale în copiile de rezervă înainte de următoarea repornire?

Există o abordare mai bună, astfel încât sistemul să pornească în continuare dacă dispozitivul principal eșuează?

1. Specificația UEFI nu are cunoștințe despre software-ul RAID. Este o deficiență cunoscută.

Aș specula, probabil, pentru că a fost influențat în mare parte de băieții Microsoft care nu au fost capabili să creeze o matrice RAID software de încredere în Windows și nu știu că este posibil să creeze o matrice din partiții cu superbloc simplu, fără un sistem intern special. structură (numai Windows poate construi matrice din discuri convertite în manager de disc logic „dinamic” sau în format de spații de stocare).

2. Puteți crea mai multe ESP-uri pe diferite dispozitive și le puteți sincroniza manual.

De exemplu, dacă instalați Proxmox VE pe „RAID software” ZFS, acesta va crea mai multe ESP-uri și va instala un „cârlig” special care rulează după actualizări de kernel, încărcător și alte lucruri legate de pornire, iar acel cârlig se va asigura că toate ESP-urile sunt menținute sincronizate.

3. Pentru ca ESP-ul de rezervă să preia controlul în cazul în care dispozitivul principal eșuează, ar trebui să configurați intrările de pornire UEFI pentru toate ESP-urile dvs. În Linux se face așa:

efibootmgr -c -d /dev/sdb -l \EFI\DEBIAN\GRUBX64.EFI -L debian-sdb
efibootmgr -c -d /dev/sdc -l \EFI\DEBIAN\GRUBX64.EFI -L debian-sdc
efibootmgr -c -d /dev/sdd -l \EFI\DEBIAN\GRUBX64.EFI -L debian-sdd
efibootmgr -c -d /dev/sda -l \EFI\DEBIAN\GRUBX64.EFI -L debian-sda

Acesta este exemplul real de la unul dintre sistemele mele gestionate. Se presupune că ESP sunt primele partiții ale fiecărui disc.Acest lucru ar trebui făcut după ce ați sincronizat conținutul ESP-urilor dvs. efibootmgr -v va confirma că toate intrările de boot pe care le creați astfel folosesc dispozitive diferite.

Vezi si: https://askubuntu.com/questions/66637/can-the-efi-system-partition-be-raided

Conținutul partiției EFI ar trebui să fie relativ stabil, așa că clonarea manuală a modificărilor către alte copii de pe alte discuri după actualizări ar trebui să fie bine. Și chiar dacă modificările nu sunt clonate, copiile vechi ar putea fi OK atâta timp cât nu sunt prea multe revizuiri în urmă.

Va porni sistemul de pe un EFI alternativ? Asta e o întrebare mai grea. Cele mai multe versiuni moderne de bios acceptă mai multe dispozitive de pornire și le pot încerca pe toate în secvență până când unul funcționează. Deci, trebuie doar să vă asigurați că sunt toate acolo și în ordinea corectă. Este posibil să fie necesar să rulați manual comanda linux pentru a actualiza lista și comanda EFI bootloader.

Cu toate acestea, ar putea fi mai bine să nu o porniți automat la eșec. Dacă discul EFI principal eșuează, poate doriți să porniți manual și să încercați oricum reparații. Dar a avea EFI de rezervă, chiar dacă nu este în ordinea de pornire, ar trebui să ușureze mult recuperarea.

Un punct de vedere alternativ -- dacă un disc dintr-un sistem raid va eșua, este probabil să eșueze atunci când sistemul este pornit. Dacă detectați această condiție înainte de următoarea pornire, puteți activa cu ușurință una dintre copiile de rezervă EFI (și poate chiar o faceți principală) până când discul eșuat este înlocuit.