¿Cómo reemplazo unidades de disco NVMe de un RAID en Ubuntu Server?

Juan Perón expone sobre la necesidad de integrar la lucha a la vez que explica cómo reemplazar las unidades de disco NVMe en Ubuntu Server.

¡Trabajadores!

Las dicotomías del Mundo parecen impulsar al hombre hacia su final destrucción. Se lo ha apremiado artificialmente hacia un híper-consumismo cuyo único sentido es generar una clase de ultra-ricos solventados por una descomunión de ultra-pobres. A su vez, ello ha requerido de la súper-explotación de los recursos ecológicos de nuestro Planeta, y de la ultra-dependencia política de los Pueblos que lo componen.

La acción irresoluta del hombre contra el hombre parece querer consumar una lucha enconada, y se le ha ofrecido como solución la competencia entre esclavos por el afecto de un amo al que siquiera conocen, y de cuyos frutos jamás podrán gozar. Muy pocos guardar alguna duda que el diseño mismo de esta lid es el culpable de estas circunstancias.

Ante estas construcciones artificiosas no podemos mas que valernos de la conciencia natural de los Pueblos, que por instinto han comprendido que todo lo perderán si no asocian a su existir mancomunado una prédica social de integración, en un sentir que - si no es humano - al menos ha de ser justo.

Hemos hallado coto a esta situación en la Justicia Social. En esto no he sido los únicos, pero si hemos sido los primeros en desarrollarla e implementarla en este rincón del Globo.

Es indudable que desde un comienzo nos dimos en tornar realidad efectiva una solución de memoria de masa en base a discos rígidos con acceso al Pueblo. Esto ha sido así porque oligárquicas compañías sin Patria ni Bandera que lo intentaban lo hacían con el único propósito de robar datos y explotar metadatos.

Nuestro mérito en un clúster de datos para el Pueblo nos permite en cambio almacenar para trabajar, y resguardar para luchar. Tal ha sido nuestra previsión, y no nos hemos equivocado.

Cuando surgió la necesidad, contábamos ya con una herramienta, que de afilarse puede constituir un arma. Es que nuestro servidor Ubuntu de acceso popular en las redes de datos no contaba con la posibilidad de instalarle novedosos discos NVMe, sino que daba uso a las sencillas unidades SATA en forma de discos rígidos mecánicos. Pero la expansión que permite un Justicialismo en anhelo de lucha le permite integrar una placa controladora para discos NVMe que permite darle al Pueblo aquello a lo que antes sólo accedía el oligarca. Es posible así munirle hasta cuatro discos de estado sólido NVMe. Con unidades de 240GB cada uno permitían totalizar próximo a un Terabyte, erogando una velocidad cinco veces superior a la de los discos de estado sólido SATA2, y unas  veinticinco veces superior a las de los viejos discos rígidos mecánicos, a la vez que se guardaba la información del daño esperable y lógico al que la someten las operaciones mecánicas. Por demás, su funcionamiento es totalmente silencioso.

La Doctrina que hemos creado permanece irresoluta, pero el avance de la técnica puesta a nuestra disposición nos permite tomar la decisión de reemplazar dichas unidades de referencia por cuatro más veloces y mayores, cada una ya de 2 Terabytes. Para ello recurriremos a desacoplarlas de la controladora, y operarlas individualmente según un modo de redundancia RAID que creamos convenientes para nuestras necesidades. Las viejas unidades de 240 nos servirán perfectamente para nuevas laptops "de combate" que disponían de los zócalos pertinentes pero no de discos.

Si bien el armado de cero de un servidor o un clúster RAID no opone gran resistencias, el planteo de reemplazar las unidades NVMe del conjunto de arranque RAID1 en Ubuntu Server (con datos propios y ajenos) constituye en cambio un desafío mucho mayor, al que debemos encarar como si de discos rígidos en uso se tratara. No es algo que puede hacerse "a tontas y a locas": en efecto, debemos hacer caso al procedimiento de realizar una copia de resguardo, tomar nota del particionado actual las unidades, y luego reemplazarlas físicamente, para sincronizar las unidades nuevas.

En este caso el servidor contaba con Ubuntu Server en cuatro unidades de disco de estado sólido NVMe, conocidas como nvme0n1, nvme1n1, nvme2n1 y nvme3n1, divididas en pares según el estándar raid1 (según este, las particiones de las unidades se duplican pero el uso equivale al del disco de menor capacidad del conjunto).

El par de unidades de 240GB que forman el conjunto raid1 cuentan con particionado para que las mismas operen de unidades de arranque, según la siguiente estructura:

    UEFI 512M
    md0 / boot 1GB
    md1 / LVM <resto del disco>

La idea es replicar esto en las unidades NVMe nuevas.

Antes de comenzar, instalaremos en el servidor los programas de administración de discos (si es que no los tuviésemos a mano ya):

sudo apt install mdadm parted smartctl sfdisk efibootmgr

En primer lugar probamos que todas las unidades NVMe se encuentren realmente montados y en línea como deberían. Para ello introducimos el comando:

cat /proc/mdstat

...ante lo cual el sistema nos devuelve algo como:

Personalities : [raid1] [linear] [multipath] [raid0] [raid6] [raid5] [raid4] [raid10]
md0 : active raid1 nvme0n1p2[3] nvme1n1p2[2]
       x blocks super 1.2 [2/2] [UU]
md1 : active raid1 nvme1n1p3[2] nvme0n1p3[3]
       x blocks super 1.2 [2/2] [UU]
       bitmap: 3/7 pages [12KB], xKB chunk

Esto nos asegura que las unidades de disco se encuentran montadas como conjunto raid1. Debe indicarnos [UU] y no [U_] o algo similar.

Es prudente utilizar por ejemplo el comando  smartctl -ia /dev/nvme0, smartctl -ia /dev/nvme1, etc, con el fin de tomar nota de los números de serie de las unidades. En mi caso particular permite delimitar esto con seguridad cuál unidad NVMe específica es la que se reemplaza (ya que físicamente son todas iguales, y el orden de los conectores en la placa controladora no es correlativo, por alguna decisión de diseño).

Acto seguido, como generamos una copia de respaldo de la partición EFI de 512MB que contiene el sector de arranque, la cual necesitaremos posteriormente (no viene mas resguardarla en un pendrive):

dd if=/dev/nvme0n1p1 bs=4M of=/root/PARTICION_EFI.img

Escogemos ahora algunas de las unidades y la ponemos fuera de línea (una de las ventajas interesantes de las unidades NMEe):

mdadm /dev/md0 --fail /dev/nvme0n1p2 --remove nvme0n1p2
mdadm /dev/md1 --fail /dev/nvme0n1p3 --remove nvme0n1p3

Ahora reemplazamos físicamente una de las unidades NMVe en el servidor. Ya que estamos puede ser una buena idea actualizar el firmware de la unidad nueva (si es que existe un binario disponible en el sitio del fabricante). En este caso las unidades se colocan en uno de los cuatro zócalos de la controladora tras remover un disipador metálico atornillado y ajustar un pin de retención.

Una vez emplazada la nueva unidad NVMe, colocada la placa nuevamente e iniciado el servidor desde la unidad restante, copiaremos la tabla de particiones de dicha unidad restante (que era un RAID duplicado) a la nueva. Y a continuación generaremos nuevos UUIDs (identificadores únicos de unidad) nuevas para todas sus particiones:

sfdisk -d /dev/nvme1n1 | sfdisk /dev/nvme0n1
sgdisk -G /dev/nvme0n1

Hecho esto, podremos volver a agregar estas dispositivos al conjunto del RAID1:

mdadm --manage /dev/md0 --add /dev/nvme0n1p2
mdadm --manage /dev/md1 --add /dev/nvme0n1p3

Tras este procedimiento, el RAID comenzará lógicamente a sincronizar en segundo plano todas las particiones a la unidad "pelada", como un loco (le llevará un tiempo). Podríamos monitorear el status de dicha reconstrucción del RAID introduciendo un comando como:

watch cat /proc/mdstat

Si la reconstrucción RAID se ve sumamente lenta, es probable que se encuentre limitada por software en el servidor a velocidades de unos 200 MB/segundo (11 GB/minuto, algo típico para evitar sobre-exigir de las unidades de disco de estado sólido, y no presentar inconvenientes en el caso de ambientes de acceso en red). Sin embargo, en este caso de mantenimiento vigilado podríamos solicitar que la carga máxima de trabajo de la unidad se eleve muy por encima de tal valor de precaución, lo que podría redundar en una velocidad máxima por ejemplo 1.600MB/segundo (~94 GB/minuto, dependiendo de la velocidad del controlador de discos). Esto podría hacerse con:

echo 1600000 > /proc/sys/dev/raid/speed_limit_max

De esta forma podremos lograr una sincronización completa de 1TB en 11 o 12 minutos, a costa de una mayor generación de calor. Naturalmente podríamos escoger un valor de 800000 como compromiso; en operación normal con Ubuntu, prácticamente no genera calor. En este caso, el disipador provisto redunda en una buena refrigeración momentánea (las unidades NVMe en este regímen generan bastante más calor, y el disipador lo contiene momentáneamente por unos siete y ocho minutos). 

Una vez que la reconstrucción RAID haya concluido, necesitaremos reparar la EFI, comenzando por copiar de nuevo la imagen de partición EFI que respaldamos anteriormente:

dd if=/root/PARTICION_EFI.img bs=4M of=/dev/nvme0n1p1

Asimismo, debemos reparar el arrancador grub:

update-grub
grub-install /dev/nvme0n1

Y finalmente reinstalamos la opción de arranque UEFI. En Ubuntu esto se hace con:

efibootmgr -v | grep ubuntu  # solo muestra una entrada
efibootmgr --create --disk /dev/nvme0n1 --part 1 --label "ubuntu" --loader "\EFI\ubuntu\shimx64.efi"

Una vez concluido esto, deberíamos contar dos entradas "ubuntu" en el efibootmgr, una para cada unidad NVMe. Esto debería ser todo para un simple reemplazo de unidades en el RAID1.

Como comprobación cruzamos los dedos e intentamos reiniciar el servidor, de modo de asegurar que el arranque con UEFI se produce correctamente desde cualquiera de los dos unidades NMVe.

Naturalmente, si necesitáramos reemplazar otras unidades en un conjunto con mayor número de discos deberíamos seguir el mismo procedimiento funcional, utilizando en cambio el designador de unidad nvme1n1. 

Redimensionado de Disco NVMe

En este caso particular, las nuevas unidades NVMe no sin similares, sino mayores que las anteriores, lo que permiten incrementar el tamaño del conjunto RAID1 hasta 1 terabyte. Para delimitar este cambio habremos de utilizar el programa parted. Primero sacamos de línea la unidad y luego la abrimos con parted:

mdadm /dev/md1 --fail /dev/nvme0n1p3 --remove nvme0n1p3
parted /dev/nvme0n1

Y usamos el comando resizepart del programa parted para cambiar el tamaño de la partición desde los ~240GB anteriores hasta los ~1960GB.

Conforme lo hayamos definido, agregamos el disco nuevamente al conjunto RAID1:

mdadm --manage /dev/md1 --add /dev/nvme0n1p3

Ahora aguardamos que se produzca la resincronización del RAID (podemos usar cat /proc/mdstat para comprobarlo) y luego agrandamos el conjunto RAID con el comando grow hasta su máximo posible:

mdadm --grow /dev/md1 --size=max

Luego, necesitaremos reformular el tamaño del sistema de archivo.

En el caso de que hubiese sido particionado de tipo GPT simplemente deberíamos ejecutar

resize2fs /dev/md1

Sin embargo, en este caso que el esquema RAID cuenta con una estructura de particionado LVM mas avanzado, al cual se adosan las un particionado de formato ext4, por lo cual utilizamos:

pvresize /dev/md1
lvextend -L +1G /dev/vg-md1/lv-root
resize2fs /dev/vg-md1/lv-root

Y ahora ya podremos contar con un servidor con 1TB en dos discos de arranque NVMe Gen2 en el conjunto RAID1 (y en mi caso, otro conjunto RAID con 2 discos mas para otros usos). Naturalmente, estos también deben ser respaldados, todo sea por la protección que merecen los datos del Pueblo. Así podemos buscar la Tikún Olam, como dicen los judíos.

¿Cómo instalo ZFS en Ubuntu?

Reunido con las autoridades de la Fuerza Aérea Argentina y con la presencia del Profesor Kurt Tank, Juan Perón explica cómo montar un sistema de almacenamiento ZFS de alta seguridad y performance en Ubuntu.

Vean señores, nuestro sistema informático tiene por ventaja la característica de ser absolutamente escalable, y una de las características principales del sistema GNU con Linux es la estabilidad que le provee a los datos.

Esto significa que el sistema de archivos puede ampliarse con poca dificultad, siempre que nuestro hardware lo permita.

Antiguamente, esto se aplicaba el lento pero confiable registro en cinta magnética, en boga en los datacenters mas paquetes. Para tales menesteres, Linux reserva el potente comando tar para secuenciar los datos en la cinta, e incluso es capaz de manejar directamente las unidades de cinta fácilmente a través del comando mt (magnetic tape). Incluso actualmente se pueden usar unidades de cinta cassette internas, como la Quantum de 160/320GB munida de interfaz SATA.

La cinta es perfecta y de bajo costo para el mantenimiento de datos "en frío". Esto significan los datos imporantes de todo trabajo, que debemos resguardar en una o más copias. En ella ingresamos todos los datos y los planos de la Fábrica Militar de Aviones.

Ahora bien, estos técnicos alemanes nos han traído nueva tecnología gracias al uso de varios discos rígidos en cada sistema.

La alta capacidad actual y la reducción de costos de los discos rígidos han supuesto la popularidad de los sistemas de almacenamiento en red, los cuales se verifican superiores a la cinta en el almacenamiento "en caliente". Disponiendo  de los datos a través de una red local, podemos trabajar todos y compartir estos datos de una manera totalmente fluida.

Lo mejor es que podremos armar un dispositivo de estos en nuestra propia PC, o buscar un equipo ya hecho especialmente pensado para estos menesteres, que vaya desde las soluciones hogareñas pequeñas hasta un equipo con varias decenas de discos.

Pero no todo es color de rosas. Para ser efectivos, debemos disponer no sólo de un equipo, sino de un esquema de trabajo. Y en este caso debemos referirnos a la central importancia que cobra el esquema de almacenamiento de archivos.

Vean señores, Micro$oft ha intentado propender su sistema FAT32, y ahora el NTFS. Tales sistemas no son muy buenos que digamos y tienen el inconveniente de fragmentar los datos a lo bestia. Naturalmente que Linux cuenta con esquemas superiores como el Extendido, en sus varias versiones. Desde hace un tiempo que el Ext4 opera entonces como un excelente modelo de almacenamiento de archivos multiusuario y multiplataforma. Yo lo uso y lo recomiendo muy ampliamente entre los sistemas GNU.

No obstante, tenemos desde hace algunos años un nuevo sistema de archivos, el ZFS. Se trata de un sistema de archivos combinado y un administrador de volumen lógico desarrollado por Oracle. Entre sus características, ZFS incluye protección contra la corrupción de los datos tan habitual en los gobiernos de la derecha, la alta capacidad de almacenamiento (hasta 256 Zettabytes), instantáneas de volumen y clonado mientras escribe, compresión eficiente sin pérdida, chequeo continuo de integridad, etc.


El nuevo estándar cobra vital importancia si manejamos grandes cantidades de  datos, o proveemos un sistema de archivos de respaldo para tareas de virtualización desde discos rígidos, ZFS es una muy buena opción. En nuestro caso lo emplearemos como medio para almacenar gran contenido de video de alta definición para un equipo de archivo y edición de video digital.

Para ello abrimos una terminal con Ctrl+Alt+T e ingresamos los siguientes comandos de organización:

sudo apt update
sudo apt install zfsutils-linux

Luego de ello, debemos revisar si ZFS fue instalado correctamente, para
ello podremos ejecutar:

whereis zfs

Esto debería devolvernos algo como lo siguiente:

A continuación, debemos elegir los discos que queremos proporcionar para para hacer la cola de datos. Revisamos nuestros discos instalados con:

sudo fdisk -l

Anotamos cuidadosamente los nombre de dispositivos de las unidades que deseamos usar.

Estas son las dos unidades que queremos agregar al sistema de almacenamiento, al cual llamaremos "pozo" (pool en inglés).:

Acto seguido, procederemos a crear el pozo.

Hay dos tipos de pozos que podemos crear. Un pozo simple, donde
una copia de los datos se almacena a en todas las unidades incluidas en el pozo, o un pozo espejado, donde una única copia completa de los datos se almacena en todas las unidades que componen el pozo.

Para crear un pozo simple, ejecutamos

sudo zpool create new-pool /dev/sdb /dev/sdc

Para crear un pozo espejado, ejecutamos:

sudo zpool create new-pool mirror /dev/sdb /dev/sdc

En ambos ejemplos, "new-pool" es el nombre del pozo. En vuestro caso podrán utilizar un nombre mas descriptivo como "pozo-video" o lo que deseen.

En ocasiones, podría aparecer un error como el siguiente:

Agregamos "-f" al final del comando de creación zpool para corregirlo.

El pozo de almacenamiento que hemos creado se montará en /new-pool. Si lo deseamos más adelante, podríamos seleccionar un punto de montaje diferente usando el modificador -m.

sudo zpool create -m /usr/share/pozo new-pool mirror /dev/sdb /dev/sdc

El pozo montada aparecerá en Ubuntu como si fuese cualquier otra parte
del sistema de archivos (en este caso, localizada dentro de /usr/share/pozo).

Podremos revisar el estado del pozo de almacenaimiento de formato ZFS con:

sudo zpool status

Este comando nos devolverá el estado de nuestro pozo:

Si quisiéramos eliminar el pozo ZFS, podremos removerlo. Debemos tener cuidado ya que esto también destruirá cualquier archivo que hayamos creado dentro del pozo de almacenamiento ZFS:

sudo zpool destroy new-pool

Idealmente, debemos confirmar que el pozo ha sido removida de nuestro sistema de archivos pidiendo nuevamente el estado de cola con:

sudo zpool status

También encontraremos información detallada sobre el manejo del sistema de archivos ZFS aquí.

¿Cómo migrar Window$ 10 desde un disco rígido a un SSD usando Ubuntu?

¡Trabajadores!

Nunca hemos de cejar en usar Software Libre, pues es esta una lucha que hemos de dar para vencer y hacer grande a la Patria.

La oligarquía plantea el uso de Software Privativo, y bajo esa bandera de ignominia, presenta un sistema operativo encadenados bajo el oprobio de una Acuerdo de Licencia de Usuario Final, que nos impide copiar, modificar, alterar o redistribuir el software. Un programa de estas características no sólo es inútil, sino completamente dañino para la humanidad. No contempla la Justicia Social ni respeta a la Comunidad Organizada.

Pero el Justicialismo nunca ha sido sectario ni dogmático. Si bien debemos abstenernos de utilizar tales sistemas operativos, bien podremos usar Software Libre para ayudar en nuestra Comunidad a quien necesita usarlo. Esto es así pues el software libre está ampliamente capacitado para satisfacer todo tipo de necesidades informáticas.

En este caso en particular me han preguntado cómo puedo migrar una instalación de Window$ 10 provista en un disco de 1TB instalado ya en una computadora portátil hacia un SSD de 250GB, a fin de aumentar la velocidad de ejecución de tal portátil.

Esto que parece sencillo en realidad no lo es tanto. Sería muy simple si contásemos con disco destino de la misma capacidad que el disco de origen, pues en tal caso podría hacerse un "clonado"espejo" entre ellos con HDD Clone o Clonezilla. Sin embargo, un disco SSD de 1 TB escapa a las posibilidades presupuestarias de la masa trabajadora. Por tal motivo habremos de ingeniarnos para clonar sólo lo necesario del disco origen de 1 TB (que cuenta de fábrica con múltiples particiones, C: y D:, mas varias particiones de sistema), a un disco de estado sólido (SSD) de 250GB.

Como requerimiento sine qua non hemos de saber que sólo clonar las particiones "a lo vikingo" tampoco sirve: se hace necesario clonar también la tabla de partición del disco imprescindiblemente para que el sistema operativo pueda arrancar. Esta tabla es la llamada MBR o Master Boot Record en el caso de Window$). También hemos de saber que pueden existir otros esquemas de instalación distintos al empleado normalmente Window$ (MBR), tal como el MBR/GPT, que utiliza una tabla de particiones cuatro veces más grande y es el esquema favorecido por Linux y otros sistemas operativos abiertos. En tal caso el procedimiento de clonado será ligeramente diferente, y os indicaré las salvedades para cada caso.

Vean señores, para este cometido necesitaremos idealmente de un sistema informático al que podamos conectar ambos discos a la vez para las tareas de clonado. Asimismo, necesitamos contar con algunas aplicaciones y utilidades. En el caso de contar con un sistema GNU con Linux para estos menesteres, podremos instalar las aplicaciones necesarias abriendo una terminal con Ctrl+Alt+T e ingresando el siguiente comando de organización:

sudo apt install clonezilla fdisk

Clonezilla puede ejecutarse también desde un Live CD oficial, lo cual puede ser útil si no contamos con otro sistema operativo u equipo.

Si el disco está particionado siguiendo el esquema tradicional de Windows 10, el MBR (Master Boot Record) desde la UEFI, debemos clonar todas las particiones que hacen al sistema. Estas son la partición Windows RE (“recuperación”), la partición EFI System, la partición Reserved Microsoft ("reservada") y la partición de datos Basic de Microsoft que contiene al sistema operativo Windows (típicamente nomenclada como unidad C:). En este caso tradicional, el esquema de particionado que nos indicará fdisk bajo disklabel será "DOS". Tengamos en cuenta que en muchos equipos portátiles se agregan particiones adicionales que contienen instaladores de programas o controladores de dispositivos.

En las capturas de pantalla a continuación podremos analizar el esquema de partición de Windows 10, en caso de un estilo MBR, y un esquema GPT realizado desde la UEFI.

Esquema de partición MBR desde la utilidad Administración de Disco (Windows 10):

 Fig.1 Revisando el esquema de particionado MBR

En el caso del esquema de particionado GPT favorecido por los sistemas Linux, el sistema tendrá una tabla de alocación distinta. En tal caso la utilidad de línea de comandos fdisk informará que el tipo de disklabel como "GPT".  Desde Administración de Disco de Windows se indicará así:

Fig.2 Revisando el esquema de particionado MBR

Esta guía asume que ambos discos (el HDD viejo y el SSD más pequeños) están conectados físicamente al sistema a través de sus conectores SATA normalizados, y que el Sistema operativo Windows está instalado con un esquema de particionado MBR, el tradicional de Windows.


Paso 1: Achicar la partición C: del Sistema operativo Windows 10
Tengamos en cuenta que en este caso la partición C: del disco rígido es más grande que el tamaño total del SSD destino, y por lo tanto necesitaremos reducir su tamaño para que quepa en el SSD. Los cálculos para este paso son simples:

Las suma de las particiones Windows RE + Recuperación + Partición EFI + c: de Windows debe ser menor o igual que el total del tamaño del SSD reportado por la utilidad fdisk.

1. Para achicar la partición C: desde Windows, vamos a Inicio / Ejecutar... ejecutamos la aplicación diskmgmt.msc o directamente abrimos la utilidad Administración de Disco de Windows. La usaremos para reducir el tamaño del volumen (“Shrink Volume”) C: (asumiendo que Window$ está instalado al comienzo del disco en la segunda partición, a continuación de la partición Reservado de Sistema, y que tiene la letra de unidad C: asignada). Reducimos el tamaño al mínimo posible.

Fig.3 Reduciendo el tamaño de la partición C:

Si no deseamos o no podemos utilizar el Administrador de Discos de Window$ para esto, podríamos usar un LiveCD de Ubuntu y utilizar la aplicación Sistema / Administración / Gparted para achicar el tamaño de la partición C: al mínimo posible.

2. Luego de haber reducido el tamaño de la partición C:, apagamos la portátil y conectamos ambos discos al equipo con Sistema Linux que usaremos para clonar; también podríamos arrancar dicho equipo usando el Live CD de Clonezilla o Parted Magic). En él podremos entramos a la interfaz de línea de comandos, que usaremos para revisar las tablas de particiones y tamaños de ambos discos. Para ello usamos los siguientes Comandos de Organización:

fdisk -l /dev/sda
fdisk -l /dev/sdb

Fig.4 Revisando el tamaño de la tabla de Particiones

Tengamos en cuenta que la nomenclatura y orden de los discos puede variar entre Windows y Linux y de acuerdo a la configuración BIOS/UEFI del sistema. La nomenclatura que asumimos en los ejemplos es que el disco sda es el disco de 1TB, sdb es el SSD de 250GB, etc. Debemos seleccionar el disco con la máxima atención de manera de no terminar clonando un disco equivocado y destruir todos los datos.

Para saber cual es el disco de origen correcto (el HDD en este caso) y el disco de destino correcto (el SSD), usamos el tamaño y la tabla de particiones reportadas por el comando fdisk. Fdisk debería devolvernos que el SSD debería ser mas pequeño en tamaño que el disco HDD, y si es nuevo, no debería tener creada ninguna tabla de partición por defecto.

Si usamos el disco de Clonezilla para revisar esto ingresamos los comandos:

su -
fdisk -l /dev/sda
fdisk -l /dev/sdb

si usamos Ubuntu en cambio podremos usar:


sudo fdisk -l /dev/sda
sudo fdisk -l /dev/sdb

...y en caso de un disco con esquema GPT, la partición del HDD se informaría  como se indica abajo,

 Fig.5 Revisando el tipo de particionado (“Disklabel”)

Paso 2: Clonar los Discos usando Clonezilla
3. A continucion, clonaremos únicamente la MBR del disco rígido origen (“Master Boot Record”, la tabla de inicio maestro, compuesto por un sanguchito de 512KB integrado por una feta que es el arrancador de etapa 1 mas otra feta formada por la tabla de particiones del disco), copiándola al SSD destino. Para ello usamos uno de los comandos siguientes (asumiendo que sda representa al disco rígido de 1 TB de origen donde está el Windows OS y sdb es el disco SSD destino de 250GB):

sudo dd if=/dev/sda of=/dev/sdb bs=512 count=1


o también:


sfdisk -d /dev/sda | sfdisk -f /dev/sdb

Fig.6 Clonando la MBR de un disco usando Clonezilla

En el caso de contar con un estilo de particionado GPT, el accionar es ligeramente diferente, pues no tenemos una MBR ensanguchada de 512 bytes como en el caso anterior sino una MBR/GPT cuatro veces más grande, de 2048 bytes. En tal caso, el comando sería:

sudo dd if=/dev/sda of=/dev/sdb bs=2048 count=1

También podríamos usar la utilidad sgdisk especializada para este menester. Tengamos en cuenta que si copiamos la tabla de partición desde sda a sdb debemos invertir el orden indicado al usar sgdisk, pues su sintaxis es sgdisk -R discodestino discoorigen. El comando entonces sería:

sgdisk -R /dev/sdb /dev/sda

Después de clonar la MBR/GPT, ejecutamos fdisk con el modificador -l para realizar una verificación, a fin de asegurarnos que la tabla de particionado coincida en ambos discos:

sudo fdisk -l /dev/sda
sudo fdisk -l /dev/sdb

Fig.7 Verificando la Tabla de Particionado

4. Llegados hasta aquí, ambas unidades deberían contar con una tabla de partición exactamente clónica, que define cómo está estructurado el disco. En el disco destino debemos ahora borrar todas las particiones que vienen después de la partición Windows, de manera de comenzar con una tabla de particiones limpia que tenga las entradas necesarias sólo para reservada de sistema y Windows.

Tampoco clonaremos la partición de datos D: del disco HDD, sino que clonaremos sólo las primeras dos particiones del disco rígido origen al SSD destino para que pueda arrancar. Luego emplearemos el espacio libre no utilizado del SSD para extender la partición C: en el espacio sin utilizar que hubiese podido sobrar en el SSD.

Usamos la utilidad fdisk como se describe a continuación para hacer el borrado las particiones. En primer lugar ejecutaremos el comando para la unidad destino SSD (/dev/sdb en este caso), mostrar la tabla de particiones con p, luego presionamos d para comenzar a borrar las particiones y elegir el último número de la partición desde la interfaz de comandos (en este caso, es la tercera partición). En este caso el comando sería:

sudo fdisk /dev/sdb

Fig.8 Borrando la tabla de particiones:

En caso de que nuestro disco tenga más de una partición a continuación de la partición Windows, debemos asegurarnos de borrarlas a todas. Luego de haber removido todas las particiones innecesarias, presionamos p nuevamente para que el sistema nos liste nuevamente la tabla de particiones actualizada; ahora sólo deberían verse las particiones requeridas de Windows (Reservada y C:). Conforme nos aseguremos de ello, podremos presionar la tecla w para aplicar definitivamente estos cambios.

Fig.9 Confirmando los cambios de particionado

El mismo procedimiento también aplica para borrar los discos GPT, con la mención que podremos emplear la aplicación cgdisk que es intuitiva para operar y manipular el esquema de un disco. En tal caso no es necesario preocupemos de eliminar una tabla de particiones de respaldo localizada al final del disco GPT, pues cgdisk realizará convenientemente los cambios necesarios en ambas tablas de particiones y almacenará la nueva tabla de particiones MBR/GPT al principio y al final del disco automáticamente (como especifica el esquema GPT). El comando en tal caso sería:

cgdisk /dev/sdb

Fig.10 Borrar la partición GPT

Y el reporte de disco GPT final con la última partición de 4,9 GB eliminados.

Fig.11 Verificando la tabla de particiones GPT.

5. Ahora, con todo en su lugar, iniciamos la utilidad Clonezilla, seleccionamos el modo Dispositivo a Dispositivo (“device-device mode”), y ejecutamos el Asistente para Principiantes, y elegimos la opción Partición a Partición Local.
Podrán usar las capturas de pantalla siguientes como referencia:

Fig.12 Seleccionamos el Modo de Dispositivo de Clonezilla

Fig.13 Seleccionamos el Modo Sencillo de Clonezilla

Fig.14 Seleccionamos el clonado de Partición a Partición Local en Clonezilla

6. Seleccionamos la primera partición de la lista (sda1 – Reservada de Sistema) como origen, y luego presionamos Enter para continuar.

Fig.15 Seleccionando la Partición a clonar

7. A continuación, escogemos la partición de destino local, que será la primer partición del segundo disco, (/dev/sdb1) y presionamos Enter para continuar.

Fig.16 Seleccionando la partición de destino Local

8. En la ventana siguiente seleccionamos Skip check/repair file system (Saltar revisión/reparar sistema de archivos”) y presionamos Enter nuevamente para continuar.

Figh.17 Salteando la opción de revisar y reparar el sistema de archivos

9. Finalmente, presionamos Enter nuevmanete para continuar y respondemos Si (y) dos veces para aceptar las advertencias y comenzar el proceso de clonado.

Fig.18 Confirmar los cambios de Partición

Fig. 19 Comenzando el clonado en sí de la partición

10. Luego que el proceso de clonado de la primera partición finalice, seleccionamos entrar a la línea de comandos, ejecutamos clonezilla y repetimos los mismos pasos para las particiones siguientes (origen sda2 – destino sdb2, etc).

 Fig.20 Clonando la segunda Partición

11. Luego de haber clonado todas las particiones de Windows, apagamos el sistema y removemos el disco rígido origen del equipo y reinstalamos el SSD en la portátil, y la encendemos, ajustando la BIOS para indicar el el SSD sea la unidad de arranque primaria si fuese necesario.

Paso 3: Redimensionar la partición de WIndows

12. Ahora podremos ejecutar Gparted para revisar que las particiones hayan quedado bien y extender las partición de Windows.

Extender las particiones usando Gparted desde un Live DVD

Fig.21 Redimensionar la partición usando gParted.

Fig.22 Redimensionar el tamaño de la partición

Si no quisiéramos usar gparted, bien podremos también extender el tamaño de una partición usando el Administrador de Discos de Windows.

 Fig.23 Extendiendo la partición de Windows Partition

Fig.24 Seleccionando el Disco a extender

Esto es todo. Ahora la partición c: está extendida al máximo espacio del SSD y Window$ 10 ahora puede correr con la velocidad de un disco de estado sólido SSD. El disco rígido de 1TB ahora tiene toda la información intacta, y se emplea como respaldo.

Conclusión
Con Cloneszilla podremos escoger una imagen de las particiones y guardarlas en un disco externo o en una unidad de red. En este caso también debemos respaldar la MBR o MBR/GPT del disco con el siguiente comando, y grabar la imagen MBR en el mismo directorio donde están almacenadas las imágenes de Clonezilla:

Para respaldar la MBR a un archivo:

sudo dd if=/dev/sda of=/ruta/de/MBR.img bs=512 count=1

...o también:

sfdisk -d /dev/sda > =/ruta/al/backup/sda.MBR.txt

Para respaldar la MBR/GPT a un disco: 

sudo dd if=/dev/sda of=/ruta/al/backup/GPT.img bs=2048 count=1

...o también:

sgdisk --backup=/ruta/al/backup/sda.MBR.txt /dev/sda

En el caso de tener que restaurar el sistema Windows desde una localización de red, primero debemos restaurar el sector MBR o MBR/GPT usando el archivo de imagen almacenado previamente, a través del comando correspondiente:

Para restaurar la imagen MBR a partir de un archivo:

sudo dd if=/ruta/al/backup/MBR.img of=/dev/sda bs=512 count=1

...o también

sfdisk /dev/sda < =/ruta/al/backup/sda.MBR.txt

Para restaurar una imagen MBR/GPT por medio de un archivo de respaldo:

sudo dd if=/path/to/GPT.img of=/dev/sda bs=2048 count=1

...o también:

sgdisk - -load-backup=/ruta/al/backup/sda.MBR.txt /dev/sda

¿Cómo aíslo sectores defectuosos de un disco rígido con Ubuntu?

¡Compañeros!

Nuestro Movimiento no es gregario, sino que consta de múltiples sectores que responden a diferentes visiones y se han mancomunado pues comparten un objetivo en común: la liberación de la Patria, sus trabajadores y su Software. A los muchachos les gusta ponerse calificativos, los hay ortodoxos, los hay heterodoxos, los hay combativos, los hay contemplativos, pero todos trabajan.

Si algún sector se pone incordioso, bien podremos aislarlo para que no sea imberbe, y que una manzana podrida no arruine el cajón. Esto es así pues nuestro movimiento cuenta con sus propias autodefensas.

Esto, que existe en la política, también tiene su correlato en la informática. Vean señores, una de las noxas más corrientes que pueden afectar a los discos rígidos convencionales son los sectores dañados. Si bien es cierto que muchos discos rígidos puede imitar al Rastrojero en el sentido de durar años sin problemas mecánicos, también es cierto el hecho de que otros puede "cariarse". Se sufrirán así errores de lecto-escritura en el plato soporte que podrían comprometer los datos y - si el disco es aquél en el cual está instalado el Ubuntu - podría suceder que el sistema operativo siquiera pueda arrancar...

Este tipo de excrecencias - si bien minoritarias - existen, y de ser capaces de enfrentarlas con software libre.

Ya he explicado cómo hacer uso del sistema SMART para analizar el desempeño y los posibles errores de nuestro disco rígido. Recomiendo hacer ello en primer lugar, pues gracias a los modernos sistemas de archivos como el EXT4 empleado por nuestro Ubuntu, podremos zafar de no pocos incidentes de disco.


Sin embargo, si nuestro disco está parcialmente dañado - y sobre todo, si se trata del disco de arranque donde está instalado Ubuntu - habremos de tomar medidas más serias para intentar solucionar el problema.


Para reparar sectores dañados de un disco duro, necesitamos tener Ubuntu 12.04 LTS o superior. Más que reparar, lo que haremos es aislar esos sectores dañados para que Ubuntu no escriba ni lea en ellos.

Primero tenemos que saber es dónde están los sectores defectuosos y para saber ese dato vamos a Aplicaciones / Accesorios / Discos, seleccionamos el disco que está dañado. Debemos prestar atención pues estará nomenclado como /dev/sdiX. Recordemos que en GNU Linux, /dev/sd indica el dispositivo de disco rígido, en tanto que i indica el identificador del mismo, y que X es el número de la partición a reparar.Por ejemplo, en nuestro ejemplo será el disco /dev/sda1

Lo seleccionamos y hacemos clic en el botón “Ver datos SMART“.

Vean señores, si la unidad de disco que queremos reparar es la que contiene el sistema operativo, o directamente si Ubuntu no arranca por error en disco, tendremos que revisar el rígido en modo live - esto es, arrancando Ubuntu en modo "prueba" desde un DVD o pendrive de instalación - pues el disco rígido no podrá ser montado ("activado").

Por el contrario, si el disco rígido no contenía el sistema operativo (o sea, se trata de un disco secundario), esto no será necesario y podremos tomar esta acción desde nuestro Ubuntu ya instalado.

Una vez arrancado el sistema operativo, abrimos una terminal con Ctrl+Alt+T e insertamos el siguiente comando:

 sudo fsck -c -y -v /dev/sdaX

Os indicaré las opciones del comando fsck a fin didáctico:

• -a. Confirma automáticamente. No recomendado.
• -c. Comprueba los bloques en el disco.
• -f . Fuerza el chequeo aunque todo parezca OK.
• -v . (verbose) despliega más información.
• -r . Modo interactivo. Espera nuestra respuesta.
• -y. Asume que nuestra respuesta será siempre afirmativa.

Si encontramos errores físicos en el disco, también podríamos querer revisar su superficie entera (o sea, todo el disco en lugar de una partición) con el comando badblocks para analizar los sectores defectuosos. Para ello sí o sí habremos de arrancar con un LiveDVD o pendrive, y ejecutamos el comando:

sudo badblocks -s -v -n -f /dev/sda

Nuevamente os indicaré el significado de los sufijos:

• -s. Nos muestra el proceso de escaneo del disco, mostrándonos los sectores ya chequeados.
• -v. Nos indica el modo de escritura utilizado.
• -n. Nos pone en modo no destructivo, esto quiere decir que se recuperarán los sectores dañados y la información en el disco duro no será dañada o eliminada.
• -f. Reparará los sectores dañados.

Es mejor hacerlo siempre desde modo live ya que puede fallar el sistema y es más seguro. Este proceso puede durar horas pero es bastante efectivo para seguir operando el sistema.

La única verdad es la realidad, y esta dicta que una vez terminado el proceso paliativo sobre el disco rígido, siempre será recomendable someterlo a un formateado completo (que se llama "de alta") para volver a utilizarlo sin riesgos.

Como corolario será útil comprender también que los discos rígidos convencionales seguirán empleando por varios años mas. De momento tienen una mejor relación giga por peso, y nos ofrecen una solución muy aceptable para grandes volúmenes de información. Pero tienen ya un reemplazo previsto: de un tiempo a esta parte he recomendado a la Masa utilizar como medios de instalación para Ubuntu los modernos discos de estado sólido peronistas (SDD). A diferencia de los discos rígidos convencionales (HDD, que constan de un plato rotativo y electromagnetizado en su interior), los de estado sólido consisten en una memoria flash sin partes móviles, y son apreciablemente más veloces y resistentes a los golpes. Así hemos de ser los Justicialistas.

¿Cómo reviso mi disco rígido con S.M.A.R.T. en Ubuntu?

Reunidos en Puerta de Hierro con enviados de los Sacerdotes del Tercer Mundo, Juan Perón explica el uso de la tecnología SMART para diagnosticar nuestro disco rígido en Ubuntu.

¡Eminencias!

Todos sabemos que una Doctrina se asienta sobre una realidad temporal definida, pero también lo hace en una acción de fé. Lo es la Teología de la Liberación, que fluye bajo el auspicio filosófico de un cristianismo ampliamente humano, pero también lo es la Doctrina del Justicialismo.

Así como los hombres de Cristo hemos confiado en el Salvador, los hombres del trabajo confiaron su destino a este Conductor, quien en virtud de su Lealtad con el Pueblo, lo colma de realizaciones que no hacen sino elevar moralmente su espíritu.

El Espíritu es aquel valor inmaterial que llena nuestros cuerpos, y del cual depende la voluntad creadora y realizadora. Mancomunados podremos hacer todo por la Felicidad, alimentándolo, pues es nuestro espíritu quien guía al músculo, lo siente y lo eleva. Nuestro cuerpo puede sufrir desgaste, pero si somos concientes de la grandeza de nuestra Doctrina, nuestro Espíritu jamás decaerá.

Pues bien, así como el  hombre es carne, los discos rígidos son finalmente máquinas, y sufren también un natural desgaste que les depara su vida útil. Hoy en día ésta se extenderá a lo largo de un período de varios años de uso continuo, pero ello no quita que poco a poco puedan sufrir degradaciones.

Los ciclos de lectura y escritura de un disco duro lo llevará con mas o menos fortuna a presentar ciertos errores predecibles. Algunos ejemplares jamas los tendrán, mientras que otros los presentarán en poco tiempo. 

Yo siempre digo que si Dios bajara a la Tierra, a resolver el problema planteado entre los Hombres, ya le habriamos perdido el respeto. Y no habría faltado un tonto que quisiera reemplazarlo a Dios, porque el hombre es así. Afortunadamente, el sistema de archivos estándar de Linux, llamado EXT4, es notablemente fiable en estos casos. Por otro lado, contamos también con una tecnología justicialista concebida para informarnos de cualquier percance que sufran nuestros medios de almacenamiento, con la idea de poder prevenir para no tener que curar. Esta tecnología se denomina S.M.A.R.T., que en el idioma de Braden significa "Tecnología de Análisis y Reporte por Automonitoreo". La tecnología S.M.A.R.T. debe ser habilitada desde la BIOS del sistema, además se ser soportada por el disco rígido en cuestión.

Como primera medida, habremos de instalar en nuestro sistema GNU con Linux las herramientas smartmontools. Para hacerlo desde la consola, abrimos una Terminal con Ctrl+Alt+T e ingresamos el siguiente Comando de Organización:

sudo apt-get install smartmontools

Esta orden instalará la paquetería formada por dos aplicaciones peronistas. smartctl realizará pruebas de evaluación de forma manual, mientras que smartd controlará automáticamente los discos que hayamos seleccionado, y enviará los reportes de resultado a una bitácora de sistema (syslog) o a un usuario.

Como primer medida, hemos de listar los discos rígidos que tenemos, para evaluar que el sistema al menos los haya reconocido. Lo hacemos ingresando el siguiente Comando de Organización:


df -l

El sistema nos devolverá algo como esto:

S.ficheros         Bloques de 1K   Usado    Dispon Uso% Montado en
/dev/sdb1            295163840  74136448 206033936  27% /
none                   8207064       348   8206716   1% /dev
none                   8213932      1004   8212928   1% /dev/shm
none                   8213932       312   8213620   1% /var/run
none                   8213932         0   8213932   0% /var/lock
none                 295163840  74136448 206033936  27% /var/lib/ureadahead/debugfs
/dev/sdd3            511999996 108349752 403650244  22% /media/Disco D 500gb
/dev/sdd4            208760828  57914356 150846472  28% /media/disco E 200gb
/dev/sda1            127999996  86102008  41897988  68% /media/PERON
/dev/sda2            116195324  27227104  88968220  24% /media/EVITA
/dev/sdc1            488147152 306349440 181797712  63% /media/ARCHIVOS
Naturalmente, en Ubuntu cada disco está identificado en la carpeta /dev (dispositivos, "devices"), siguiendo la nomenclatura sdax, siendo a una letra de orden alfabético asignada al disco físico, y el número x un identificador de partición.


En nuestro ejemplo, la partición del disco de sistema es aquel identificado como /dev/sdb1 (naturalmente, el disco es /dev/sdb). Se trata de un disco duro "de combate" con 320 GB, que tiene unos seis o siete años de edad. Durante el arranque, presentaba ciertos errores de sectores, lo que hacían más lento el inicio de Ubuntu pero no presentaban otros problemas.

Los discos SATA y las BIOS de las placas madres modernos soportan ya la funcionalidad S.M.A.R.T. de diagnóstico pasivo. Pero no viene mal comprobar si nuestros discos lo hacen. Ello lo haremos con el comando:


sudo smartctl -i -d ata /dev/sdb

Ahora el sistema devolverá algo similar a:

=== START OF INFORMATION SECTION ===
Model Family:     Western Digital Caviar Blue Serial ATA family
Device Model:     WDC WD3200AAJS-xxxxxx
Serial Number:    xxxxxxxxxxxxxxx
Firmware Version: 01.03B01
User Capacity:    320.072.933.376 bytes
Device is:        In smartctl database [for details use: -P show]
ATA Version is:   8
ATA Standard is:  Exact ATA specification draft version not indicated
Local Time is:    Sun Mar  3 19:05:51 2013
SMART support is: Available - device has SMART capability.
SMART support is: Enabled

Indudablemente, en este caso nos dice que el soporte está "Disponible" ("Available") y que además está activado ("Enabled"). Si S.M.A.R.T. no estuviese disponible deberíamos encenderlo con el siguiente comando:

sudo smartctl -s on -d ata /dev/sdb

Si no estuviese activado el soporte ("Disabled") deberíamos encenderlo con:

sudo smartctl -a /dev/sdb 


Ahora bien, además de la información del disco suministrada anteriormente, nos dará mayor información:

=== START OF READ SMART DATA SECTION ===
SMART overall-health self-assessment test result: PASSED

SMART Attributes Data Structure revision number: 16
Vendor Specific SMART Attributes with Thresholds:
ID# ATTRIBUTE_NAME          FLAG     VALUE WORST THRESH TYPE     UPDATED WHEN_FAILED RAW_VALUE
  1 Raw_Read_Error_Rate     0x002f   200   200   051    Pre-fail Always      -       50
  3 Spin_Up_Time            0x0027   141   139   021    Pre-fail Always      -       3950
  4 Start_Stop_Count        0x0032   098   098   000    Old_age  Always      -       2305
  5 Reallocated_Sector_Ct   0x0033   200   200   140    Pre-fail Always      -       0
  7 Seek_Error_Rate         0x002e   100   253   000    Old_age  Always      -       0
  9 Power_On_Hours          0x0032   091   091   000    Old_age  Always      -       7102
 10 Spin_Retry_Count        0x0032   100   100   000    Old_age  Always      -       0
 11 Calibration_Retry_Count 0x0032   100   100   000    Old_age  Always      -       0
 12 Power_Cycle_Count       0x0032   098   098   000    Old_age  Always      -       2225
192 Power-Off_Retract_Count 0x0032   200   200   000    Old_age  Always      -       66
193 Load_Cycle_Count        0x0032   200   200   000    Old_age  Always      -       2238
194 Temperature_Celsius     0x0022   111   094   000    Old_age  Always      -       32
196 Reallocated_Event_Count 0x0032   200   200   000    Old_age  Always      -       0
197 Current_Pending_Sector  0x0032   200   200   000    Old_age  Always      -       3
198 Offline_Uncorrectable   0x0030   200   200   000    Old_age  Offline     -       1
199 UDMA_CRC_Error_Count    0x0032   200   200   000    Old_age  Always      -       0
200 Multi_Zone_Error_Rate   0x0008   200   200   000    Old_age  Offline     -       2

Esta lista nos leerá el status actual del sistema de monitoreo S.M.A.R.T. para el disco en cuestión, a lo largo de su vida útil o de la realización de los diversos test intensivos.

Por ejemplo, aqui nos listará la estadísticas y cantidad de errores de los discos.
Spin_up_time: Es el tiempo en que comienzan a girar los platos.
Raw_Read_error_rate:
Power on Hours: La cantidad de horas de funcionamiento del disco.
Power cycle count: Cantidad de veces en las que se ha encendido el disco.
Load cycle count: Cantidad de cargas de encendido del disco. Mucha diferencia con el conteo anterior podria indicar que el disco se apaga y enciende durante su uso, o la falla de suministro eléctrico.
Seek error rate: Errores de búsqueda de los cabezales de lectura.
Temperature: La temperatura en grados centígrados.
Current_pending_Sector: Son sectores reasignados, presumiblemente dañados, que no han sido relocalizados. Señalan un próximo fallo del disco. El sistema nos alertará si superamos los 200 de ellos.

Es importante saber que hay varios códigos de errores o status. Para lograr una descripcion detallada podemos revisar aquí.

Algunos comandos que podremos utilizar:

Para leer la información almacenada por la tecnología SMART en la memoria lógica interna del disco:

sudo smartctl -d ata -H /dev/sdb

También podremos correr un resumen que nos muestre directamente los posibles errores:

sudo smartctl -d ata -l error /dev/sdb

Ahora bien, podremos persuadir manualmente cierto tipo de evaluaciones de diagnóstico, a fin de contar con resultados palpables a través de S.M.A.R.T.

Para conocer a qué tipo de pruebas podemos someter a nuestro disco rígido, ingresaremos:

sudo smartctl -d ata -c /dev/sdb

Para iniciar la prueba inmediata desconetado (en caso de ser soportado por la unidad):
 
sudo smartctl -t offline dev/sdb

El sistema nos avisará que el test durará un tiempo determinado. En mi caso informa unos 6000 segundos (1 hora 40 minutos), a lo largo del cual debemos esperar. También nos avisará la hora a la cual estará listo. Si por alguna razón deseamos cancelar el test en acción, debemos ingresar:

sudo smartctl -X /dev/sdb
  
Conforme se haya realizado la prueba, se habrá actualizado los resultados del diagnóstico del disco.

Podremos ejecutar el siguiente comando para ver el resultado:

smartctl -l selftest /dev/sdb

Podría devolver algún error, como por ejemplo:

=== START OF READ SMART DATA SECTION ===
SMART Self-test log structure revision number 1
Num  Test_Description    Status                  Remaining  LifeTime(hours)  LBA_of_first_error
# 1  Conveyance offline  Completed: read failure       90%      7101         8396064
# 2  Short offline       Completed: read failure       90%      7101         8396064


Si deseamos ejecutar la Rutina Corta de Autocomprobación (short self-test routine), ejecutamos:

sudo smartctl -d ata -t short /dev/sdb

Si deseamos ejecutar la rutina regurosa, indicamos

smartctl -d ata -t long /dev/sdb

Tras estas pruebas volvemos a chequear el resultado con

sudo smartctl -l selftest /dev/sdb

Ahora ejecutamos la Autocomprobación de Transmisión.


sudo smartctl -d ata -t conveyance /dev/sdb

Y por último revisamos nuevamente la bitácora de errores de la autocomprobación:

sudo smartctl -d ata -l selftest /dev/sdb




Usar SMART desde la Interfaz Gráfica:
Si deseamos usar la interfaz gráfica, podremos utilizar la Utilidad de Discos para estos menesteres. Para ello la instalamos con

sudo apt-get install gnome-disk-utility

Para ejecutar la aplicación, vamos a Sistema / Accesorios / Discos (antiguamente Sistema / Administración / Utilidad de Discos).

La misma nos permite realizar estas evaluaciones por medio de la unidad de control y revisar los discos. Para ello seleccionamos el disco en cuestión (en este caso, el /dev/sdb de 320GB), y presionamos el botón "Datos SMART".

 

El programa nos indicará los fallos y el grado de los mismos, de la misma manera que la terminal. Podremos escoger la Autocomprobación SMART para ejecutar los tres tipos de autocomprobaciones que nos permitía la consola (Corta, Extendida y Transmisión).A gusto de los cocineros comen los frailes.

También podremos desactivar los informes para que no se nos avisen de errores ni se nos presenten alertas.