Ara ho he vist. Buscava al "man fsck" i no trobava la opció.

Ja que hi som, llanço una consulta. Tinc configurat un sistema de backup
amb un Raspberry PI (raspbian stable+debian armhf stable) al quan accedeixo
remotament via SSH. Totes les gestions de manteniment personalitzades (que
no venen per defecte) les executo mitjançant script  BASH a través de SSH
--una forma que em resulta pràctica per què centralitzo el manteniment--.

El cas és que si intento executar fsck  -vMsrp -t ext 4 sobre la UUID  i a
través de SSH de la partició que vull revisar em dóna error (return code
8). No em dóna més informació. En canvi, la mateixa sentència executada amb
una terminal interactiva no em dóna cap problema. Vull creure que és degut
a alguna variable d'entorn. Però no sé per on continuar amb la
investigació. Alguna idea?

Gràcies.
Toni Mas


Missatge de Jordi Funollet <funol...@fastmail.fm> del dia dj., 29 de nov.
2018 a les 10:15:

> Hola Toni,
>
> has de buscar a 'man fsck.ext3', que té opcions específiques per aquest
> filesystem. 'man fsck' sols t'ensenyarà les opcions comunes a tots els
> filesystems.
>
> --
> Jordi Funollet Pujol
> http://www.linkedin.com/in/jordifunollet
>
> On Thu, Nov 29, 2018, at 9:50 AM, Toni Mas i Soler wrote:
> > Hola,
> > Disculpeu la ignorància. Per curiositat. No he trobat en cap documentació
> > el què implica la opció -cc del fsck (doble). Algú sap què és el seu
> > significat exacte?
> >
> > Gràcies.
> > Toni Mas
> >
> >
> > Missatge de Narcis Garcia <debianli...@actiu.net> del dia dt., 27 de
> nov.
> > 2018 a les 15:06:
> >
> > > __________
> > > I'm using this express-made address because personal addresses aren't
> > > masked enough at this mail public archive. Public archive administrator
> > > should fix this against automated addresses collectors.
> > > On 27/11/18 14:49, Eloi wrote:
> > > > El 27/11/18 a les 09:48, Narcis Garcia ha escrit:
> > > >> [...]
> > > >> El què vaig fer és reiniciar a una unitat externa i:
> > > >> $ fsck -ccyk /dev/sda1
> > > >
> > > > Uf. A banda de la recomanació que ja t'han fet de ddrescue per treure
> > > > una imatge del disc, fer un fsck -cc sobre un disc que dóna errors i
> > > > conté dades a recuperar és una *terrible* idea. La prova "no
> destructiva
> > > > de lectura i escriptura" de badblocks consisteix a llegir un sector,
> > > > guardar-lo en memòria, escriure noves dades, llegir-les, verificar
> que
> > > > són les que just ha escrit i reescriure les dades originals.
> > > >
> > > > Ja no és només risc inherent d'escriure sobre un disc que ja ha donat
> > > > indicis de fallada (raó per la qual és recomanable sempre muntar en
> > > > només lectura particions de discs amb danys si no és possible un
> > > > ddrescue), el fet de sobreescriure sobre *tots* els sectors pot
> haver no
> > > > només augmentat els errors de lectura sinó haver destruït dades fins
> > > > aleshores recuperables en cas que el cicle de llegir, escriure,
> > > > comprovar i sobreescriure amb les dades originals falli en els últims
> > > > passos.
> > > >
> > > > No puc ajudar-te en l'aspecte de recuperar directoris, només puc
> dir-te
> > > > que no tornis a fer un fsck -cc sobre un disc amb errors i dades a
> > > > recuperar. El que faria ara, per no agreujar encara més la situació,
> > > > seria crear amb ddrescue una imatge del disc i fer servir eines de
> > > > rescat sobre *còpies* d'aquesta imatge que has creat. El problema és
> que
> > > > fer-ho sobre segur suposa disposar d'un mínim de 2x l'espai del disc
> > > > original.
> > > >
> > >
> > > Vaig fer la revisió de lectura+escriptura perquè he llegit que el
> > > sistema SMART només reubica sectors quan falla l'escriptoria, i volia
> > > poder copiar-me les dades (corruptes o no) sense que s'interrompés res
> > > per fallades de lectura. També la meva intenció era que el fsck fes la
> > > seva reubicació de blocs; no m'importa gaire que es perdin fitxers
> d'uns
> > > quants blocs defectuosos; m'importa el conjunt de centenars de milers.
> > >
> > > No disposo d'espai per jugar amb una partició de 3TiB
> > > La meva esperança és només recuperar algunes eestructures d'inodes.
> > >
> > > Crec que el problema amb fsck ha estat més lògic que físic: els inodes
> > > illegibles (i orfes) deuen haver estat «matxacats». Però... sorpresa!
> > > dins de /lost+found hi han anat a parar centenars de milers de
> > > directoris i fitxers!
> > >
> > >
>
>

Respondre per correu electrònic a