Oi lokize,
O gparted está claramente identificando que as partições sdb1 e sdb5 estão vazias, onde supostamente deveriam estar, segundo seu relato, respectivamente, o sistema operacional e os arquivos de dados.
Entretanto, se vê a partição sdb2, formatada em ntfs, com uma quantidade expressiva de ocupação. Como v. não afirma com absoluta certeza que eram realmente essas as partições utilizadas quando da instalação (sb1 e sb5), o primeiro e mais óbvio passo é verificar de forma extensiva se os seus dados não estariam mesmo armazenados nessa partição sdb2.
Enquanto se procura identificar mais precisamente o problema e o que é que veio a ocasionar isso, me preocupa especialmente o seu grau de familiaridade operacional com a solução de problemas dessa espécie, vez que qualquer passo errado pode agravar o problema, levando a dificultar ou até mesmo impossibilitar a recuperação dos dados.
Se os dados desaparecidos são realmente muito importantes, creio que a primeira coisa a se fazer, antes de tentar qualquer procedimento. é obter uma imagem binária desse disco identificado como sdb. Isso dá a possibilidade de que qualquer passo errado possa ser revertido.
Apenas que para obter essa imagem binária é necessário que esteja disponível um outro disco de ** igual ou superior tamanho ** (nunca menor) para o qual se irá copiar uma imagem de sdb. Um bom técnico, creio eu, faria dessa forma antes de tentar qualquer coisa, sempre, claro, na suposição da imprescindibilidade dos dados desaparecidos.
É importante perceber que, nessa hipótese, o disco destino será inteiramente apagado, ou mais precisamente, sobre ele será gravada a imagem de sdb, portanto, você **não** pode usar um disco ativo com outros dados, sob pena de perdê-los também.
Se for viável conseguir plugar um outro disco no sistema para essa cópia binária, de baixo nível, então você poderá usar o recurso do programa "dd", que é um utilitário padrão do Linux.
Não há a mais absoluta certeza que o dd vá funcionar, pois podem ocorrer erros que impeçam o processamento, mas penso ser uma boa primeira alternativa de cópia de segurança da imagem.
Ao plugar um outro hd no sistema com essa específica finalidade ele passará a ser identificado por uma letra adicional, provavelmente sdd, mas enfim, uma vez plugado basta entrar no sistema via liveCD e verificar pelo fdisk -l acompanhado do gparted, como já vimos. Daqui em diante vou referenciar como sdd, porém lembrando que isso deve ser adequado ao caso concreto.
Note que para fazer essa cópia binária, de baixo nível, ambos os discos, o de origem e o de destino, precisam estar desmontados. Isso significa que, estando no ambiente gráfico, v. *não pode* clicar sobre os icones respectivos, pois ao fazer isso ocorre a montagem. De toda forma, se estiverem aparecendo como montados, basta clicar no botão direito do mouse e mandar desmontar, ou ainda dentro da janela Locais/Computador acionar o botão de ejetar, para ocorrer o desmonte.
A imagem binária do hd vai resultar em uma cópia bit a bit do hd, incluindo trilha MBR, tabela de partições e tudo o mais que tiver lá dentro, exatamente do jeito que está. É uma imagem mesmo, idêntica, ou seja, vai clonar o hd, e essa é a vantagem, por permitir restauração posterior, no caso de alguma coisa dar errado, além de permitir que se faça as tentivas nessa cópia da hd gerada (sdd) ao invés da hd original (sbd).
Se conseguir plugar esse hd adicional para essa finalidade de criar uma imagem, o comando a ser utilizado é:
sudo dd if=/dev/sdb of=/dev/sdd
Nota importante: outra vez, ***não use*** esse comando tendo como destino um disco ativo, pois vai destruir o conteúdo do destino, sobrescrevendo os dados.
A primeira parte do comando é a origem (sdb) e a segunda parte o destino (sdd), lembrando novamente que o sdd destino aqui é hipotético, devendo ser substituído pela letra concreta que aparecer quando se plugar a nova hd.
Se por qualquer razão não estiver disponível ou não for possível obter um hd adicional para essa específica finalidade (que é a opção preferida), é possível criar a imagem em um hd existente desde que haja espaço suficiente para isso.
Não gosto muito dessa alternativa, porque aumenta a possibilidade de que v. cometa um erro aí e agrave o problema, além do que vai mexer em um outro disco ativo, o que não é bom, mas enfim.
Nesse caso, o que se observa pelo fdisk é que v. possui um disco de 1 Terabyte, que está em sda1, no qual talvez seja possível criar um espaço para copiar a imagem do disco problemático (sdb).
Nesse disco de 1TB é necessário ter um espaço livre de pelo menos 400GB, só assim dará para fazer.
Diferentemente do procedimento anterior, v. terá que montar o disco sda, o disco de destino, para o que basta clicar no icone correspondente e a montagem é feita automaticamente.
O Ubuntu usa como ponto de montagem o diretorio /media, então é isso que será usado para copiar a imagem.
Supondo o disco de destino montado (sda montado), o que se vai fazer é copiar o disco sdb problemático como um arquivo de imagem em sda, de tal forma que se der algum erro na tentativa posterior de consertar o sdb, sempre será possível retornar a imagem gravada em sda para sdb, retornando ao status quo ante.
Só que aqui temos uma especificidade do Ubuntu, pois ele usa o conceito de uuid (universally unique identifier) para identificar os dispositivos quando montados.
UUID, só para entender, é a atribuição de um número único a um dispositivo de armazenagem, calculado segundo certos parâmetros, facilitando a identificação do dispositivo mesmo quando ele é mudado de porta dentro do sistema, por exemplo, nos conectores SATA da motherboard, tira da porta 0 e passa para a porta 1 e assim por diante, mesmo com a mudança o Ubuntu consegue identificar o disco a partir desse uuid, grosso modo é isso.
Assim sendo, creio que não será possível usar no comando dd a identificação que v. vê no gparted (sda1) e sim substituir isso pelo específico uuid que aparece quando o disco de destino está montado.
O caminho que me parece mais fácil aqui, para achar esse uuid do sda1 estando no sistema pelo liveCD, é montar o sda (clicando no ícone corresponde), ir para o terminal e usar o blkid através do seguinte comando:
sudo blkid | grep sda
Vai obter uma saída semelhante a isso:
/dev/sda1: UUID="884E62CB4E62B21C" TYPE="ntfs"
Navegue para o diretório /media e confirme.
cd /media
ls
Você deverá estar vendo sob o diretório /media exatamente esse mesmo uuid, algo assim como saída do ls:
0792-881A 884E62CB4E62B21C apt cdrom fat32
Então, agora que já temos o uuid do disco de destino, vamos retornar à geração da imagem propriamente dita.
O comando a ser utilizado para gravar a imagem deveria ser esse:
sudo dd if=/dev/sdb of=/media/sda1/sdb.img
Esse comando está dizendo para pegar o disco sdb e copiar como imagem, com o nome sdb.img na partição sda1, o que vai acontecer na raiz da partição.
Mas como disse, creio que isso não vai funcionar no Ubuntu, por causa do uso do uuid, então onde estiver sda1 v. vai substituir pelo uuid anteriormente obtido.
sudo dd if=/dev/sdb of=/media/uuid_obtido_antes/sdb.img
uuid_obtido_antes você substitui pelo número real obtido.
No exemplo aqui hipotético ficaria assim (no seu computador terá um outro número de uuid para sda1, específico):
sudo dd if=/dev/sdb of=/media/884E62CB4E62B21C/sdb.img
Essa cópia da imagem de sdb para sda1 vai demorar muito tempo para ser realizada, já que estamos falando em copiar algo como 360GB ou mais e o programa dd, que é muito simples, em linha de comando, não dá nenhuma indicação de andamento, fica apenas piscando o cursor até ele terminar.
Existem outras formas e outros programas para fazer isso, mas o que acho simples nesse procedimento é que ele usa apenas o que está imediatamente disponível no Ubuntu.
Se antes de tentar essa maratona v. quiser melhor se familiarizar com isso tudo, faça um teste, um pequeno experimento, com o uso dos comandos até aqui descritos usando coisas mais simples e menos demoradas.
Por exemplo, teste copiar um cd-rom qualquer (formato até 700MB para ser mais rápido, ou seja, melhor não usar um dvd, que vai demorar mais) e o copie para um pendrive qualquer colocado no seu computador.
Apenas note que o Ubuntu monta o cd-rom colocado na gaveta em /dev/sr0 (aqui é zero e não letra O, de Orlando!).
Então, como experimento de familiarização:
1) plugue um pendrive vazio ou não, nada impede que haja arquivo dentro dele, porém com capacidade de pelo menos 1GB de espaço livre no seu computador (porque o cd-rom tem 700MB), sistema carregado pelo liveCD, o sistema vai atribuir a ele uma letra, possivelmente sdd;
2) coloque o cd-rom que se quer copiar na gaveta;
3) monte o pendrive clicando no ícone correspondente;
4) obtenha pelo gparted a letra que foi atribuída ao pendrive (no terminal sudo gparted, canto direito superior, alterne os discos para ver o pendrive, vamos supor aqui no exemplo que tenha sido sdd);
5) Obtenha no terminal o uuid do pendrive
sudo blkid | grep sdd
Como exemplo de saída: /dev/sdd1: UUID="0792-881A" TYPE="vfat"
6) Execute o comando de geração da imagem (aqui uuid exemplificativo):
dd if=/dev/sr0 of=/media/0792-881A/sr0.img
7) Ao final do processamento você verá algo semelhante a isso:
52148+0 registros de entrada
52148+0 registros de saída
26699776 bytes (27 MB) copiados, 16,3921 s, 1,6 MB/s
No seu pendrive de destino tem agora um arquivo com o nome sr0.img, que corresponde à imagem do cd-rom fonte.
Mais uma vez, note, por favor, que nada disso resolveu realmente o seu problema, que é achar os seus arquivos. Tudo o que fizemos até aqui foi gerar uma cópia imagem do seu disco problemático com a intenção de melhorar a segurança, como boa técnica, para o caso de algum passo errado na tentativa de recuperação, permitindo retornar.
No momento creio que seja isso, esperando que os experts existentes aqui no Fórum nos auxiliem nessa tarefa de identificar e resolver o problema.
[]'s
