Has trabajado muy duro para darle forma a tu sistema y has solucionado todos los errores, pero sabes que las cosas no duran para siempre, y es posible que recibas una actualización con un navegador corrupto, o que quieras experimentar con un nuevo kernel o paquete beta. Para evitar futuros problemas, siempre es bueno hacer una copia de seguridad o backup. Sin embargo, las copias de seguridad suelen ser algo que llevan a confusión en los foros, y muchos usuarios novatos tienen dificultades a la hora de hacerlas. En este artículo, vamos a aprender qué debemos hacer para que nuestro sistema esté siempre seguro.
Discos, particiones y sistemas de archivos
Los usuarios informáticos experimentados no sulene tener problemas a la hora distinguir entre discos, particiones y sistemas de archivos. No obstante, para que todos partamos de un mismo punto vamos a analizarlos. Un disco generalmente es un dispositivo físico que almacena datos en bloques accesibles al azar. En configuraciones más complejas, es posible combinar múltiples discos físicos como matrices RAID utilizando para ello un determinado hardware o software, y que son presentados al sistema operativo como discos virtuales. Las particiones son secciones dentro de los discos que generalmente tienen un sistema de archivos. Los sistemas de archivos gestionan cómo se almacenan los archivos y los datos para poder localizarlos más tarde. Para realizar una copia de seguridad de tu sistema ODROID, deberá conservar la información el contenido de las particiones.
Todos los discos empiezan con un bloque de datos de 512 bytes que generalmente contiene el gestor de arranque (para sistemas x86, 446 bytes) y el Registro Maestro de Inicio (MBR) 64B, el cual se explica en http://bit.ly/2bMCTUh. El MBR es una tabla con el offset inicial, la longitud y los tipos de particiones de tus 4 particiones primarias. Estas son las particiones asignadas del 1 al 4 en el kernel Linux (por ejemplo, sda1, sda2, sda3, sda4 para un disco llamado sda). El MBR es una estructura de datos antigua, introducida en 1983, de modo que tiene algunas limitaciones. La necesidad de utilizar discos cada vez más grandes (> 2 TB) dio lugar a la introducción de la tabla de particiones GUID (GPT) que reemplaza al MBR en los nuevos sistemas, tienes más información en http://bit.ly/2bvb4oL. Los ODROID pueden usar tanto MBR como GPT, pero el sistema de arranque está diseñado como un volumen MBR debido a su tamaño relativamente pequeño y simplicidad.
Aunque, tal y como se puede apreciar en la Figura 1, un disco puede tener más de 4 particiones. Esto se consigue recurriendo a un truco: una partición primaria se marca como "extendida" y puede contener tantas particiones lógicas como se quiera. Linux las representa con números desde el 5 en adelante (es decir, sda5, sda6, etc.). La información de las particiones lógicas se almacena en estructuras similares al MBR llamadas Registro de Arranque Extendido (EBR) tal y como se explica en http://bit.ly/2bw47Re, que se muestra como una lista vinculada tal y como se puede apreciar en la Figura 2, y que precede a la partición real del disco.
Las particiones que generalmente verás en los ODROIDs son FAT16/FAT32 (se ven como VFAT bajo el comando mount) y Ext2/3/4. Existen otros tipos de particiones compatibles con Linux, como NTFS, XFS y ZFS, pero por lo general no son esenciales para el proceso de arranque, de modo que las dejaremos a un lado. Existen herramientas para hacer copias de seguridad como BackupPC (http://bit.ly/2bx3J6R) o Clonezilla (http://bit.ly/1Iq2mN7), que admiten más tipos de particiones o que hacen copias de seguridad a nivel de archivos. Estas mismas herramientas deberías utilizarlas para hacer copias de seguridad de tus datos personales, como archivos, imágenes o música. Tampoco está de más antes de empezar a hacer una backup llevar a cabo una "limpieza a fondo" para eliminar las cosas que ya no necesites, como son archivos temporales o descargas, con el objetivo de reducir el tiempo que se necesita para hacer la copia de seguridad y el tamaño del archivo de backup. Por ejemplo, puedes eliminar la memoria caché de los paquetes apt descargados con el siguiente comando:
$ sudo apt-get clean
Estrategias para hacer Backup
Hay unas cuantas formas de hacer una copia de seguridad de tu tarjeta SD/eMMC. La más simple de implementar es hacer una copia binaria 1:1 de los datos en un archivo de imagen. Para esta tarea, puede usar una herramienta como dd o Win32DiskImager. Ten en cuenta que todos los comandos que introduzcas a continuación necesitan tener la variable $backupDir reemplazada por la ruta del directorio de la copia de seguridad, que no puede estar en la misma partición de la que intentas hacer una copia de seguridad por razones obvias.
$ sudo dd if=/dev/mmcblk0 of=$backupDir/backup.img bs=1MEn el comando anterior, "if" representa "el archivo de entrada" y debe apuntar al dispositivo del bloque que representa tu disco, como /dev/mmcblk0, y "of" representa “el archivo de salida" donde se deben escribir los datos. El parámetro "bs" representa "el tamaño del bloque", que viene a representar la cantidad de datos que se leen y escriben al mismo tiempo. Una variante del comando dd que muestra el progreso es el comando "pv" (visor de información):
# apt-get install pv # dd if=/dev/mmcblk0 bs=1M | pv | dd of=$backupDir/backup.imgRestaurar los datos es igual de fácil: simplemente reemplaza los valores de "if" y "of":
$ sudo dd if=$backupDir/backup.img of=/dev/mmcblk0 bs=1MTen en cuenta que dd hace una copia binaria de tu disco. Esto significa que también copiará el espacio disponible de tu disco. El archivo de salida por defecto será tan grande como el disco, lo cual significa que copiar una tarjeta SD de 64GB en su mayor parte vacía te llevará bastante tiempo y ocupará mucho espacio. La ventaja que tiene es que luego puedes ejecutar herramientas como PhotoRec (http://bit.ly/1jwXElB) sobre el espacio libre y posiblemente, recuperar archivos eliminados, lo cual es muy útil cuando se realizan análisis forenses de datos o se intentar recuperar soportes defectuosos. La desventaja pasa por tener una imagen muy grande que será lenta de copiar. Puedes usar dd junto con gzip para reducir un poco el tamaño de la imagen antes de escribirla, pero no ahorrarás tiempo:
# dd if=/dev/mmcblk0 bs=1M | gzip -c > $backupDir/backup.img.gz # gunzip -c $backupDir/backup.img.gz | dd of=/dev/mmcblk0 bs=1MTambién ten en cuenta que, en teoría, puede hacer una copia de seguridad con dd de un sistema activo copiándolo mientras están montadas las particiones, pero existe el riesgo de que aparezcan inconsistencias si los archivos son modificados durante el proceso de copia de seguridad. Lo mejor es hacer una copia de seguridad de un sistema desconectado extrayendo la tarjeta eMMC/SD, conectar ésta a un sistema diferente y hacer la copia de seguridad sin tener particiones montadas. Existe una desventaja añadida cuando se hacen copias de soportes con tamaños ligeramente diferentes. Como no todas las tarjetas de 16 GB tienen exactamente el mismo tamaño, puedes acabar con una partición truncada en destino
La utilidad "dd" tiene la ventaja de que es fácil de usar, pero para lograr una cierta velocidad en el proceso de backup/restauración y minimizar el espacio de copia de seguridad necesario, debes descomponer la operación de copia de seguridad en varios pasos evitando así hacer una backup del espacio libre. Para ello, necesitarás hacer una copia de seguridad de MBR + EBR, del gestor de arranque y de las particiones individuales.
Aun así, puedes hacer un poco chapucero y usar dd si usas gparted para reducir tu última/mayor partición a solo el tamaño utilizado, dd hasta ese tamaño, luego redimensionar la partición al tamaño original tras restaurarla, pero esto implica un poco de trabajo manual.
Copia de seguridad y restauración del MBR
El MBR y EBR son estructuras de datos pequeñas y se pueden respaldar fácilmente con dd. Pero dado que la posición de EBR en el disco puede variar, debes valerte de una herramienta de partición para extraer y restaurar los datos del MBR/EBR. Dicha herramienta es sfdisk:
$ sudo apt-get install sfdisk $ sudo sfdisk -d /dev/mmcblk0 > $backupDir/partition_table.txtPara restaurarlos más tarde, necesitarás poner el archivo guardado a disposición de sfdisk del siguiente modo:
$ sudo sfdisk /dev/mmcblk0 < $backupDir/partition_table.txtTen en cuenta que sobrescribir el MBR en un disco con particiones existentes equivale a eliminar las particiones, puesto que el sistema operativo ya no podrá encontrar los offsets de las anteriores particiones, así que recurre a la restauración con extremo cuidado. Esta copia de seguridad se puede realizar en un sistema activo sin riesgos ya que las tablas de partición generalmente no se modifican durante el tiempo de ejecución.
Copia de Seguridad y rastauración del Gestor de Arranque
Los ODROID utilizan U-Boot como gestor de arranque, tal y como se detalla en el número de noviembre de 2015 de ODROID Magazine (http://bit.ly/2bA3P9g). U-Boot almacena su código y los datos en el espacio no asignado después del MBR y al comienzo de la primera partición. También hay un poco de código de arranque en los primeros 446 bytes del primer sector, antes de la tabla de particiones. Puesto que el tamaño y la estructura del U-Boot pueden variar entre los diferentes modelos ODROID, lo más seguro es realizar una copia de seguridad binaria de este espacio no asignado con dd. En primer lugar, debes averiguar el sector de inicio de la primera partición con sfdisk:
$ sudo sfdisk -l /dev/mmcblk0
Tal y como se indica en la Figura 3, la primera partición (loop0p1) empieza en el offset 49152, de modo que necesitaremos copiarlo todo hasta el sector 49151, incluido éste. El parámetro bs (tamaño de bloque) debe coincidir con el que reporta sfdisk en la línea "Units": line:
$ sudo dd if=/dev/mmcblk0 of=$backupDir/bootloader.bin bs=512 count=49151Ten en cuenta que el comando dd también copiará sobre el MBR, que es el sector 0). Para restaurar el gestor de arranque omitiendo la tabla de particiones, puedes usar el siguiente comando:
$ sudo dd if=$backupDir/bootloader.bin of=/dev/mmcblk0 bs=512 skip=1 seek=1También debes restaurar el código de arranque desde el primer sector:
$ sudo dd if=$backupDir/bootloader.bin of=/dev/mmcblk0 bs=446 count=1Para restaurar la tabla de particiones igualmente, no añadas los parámetros skip y seek. Esto también se puede hacer sobre un sistema activo ya que los datos son mayoritariamente de solo lectura.
Copia de seguridad y restauración de particiones FAT
Por defecto, las imágenes de Hardkernel vienen con una partición FAT16/32 montada en /media/boot que contiene los archivos del kernel, initrd, árbol del dispositivo y boot.ini. Todos estos son cruciales para el arranque del sistema. Los sistemas Android muestran esta partición como almacenamiento "sdcard".
Existen varias herramientas para Linux que permiten respaldar particiones FAT. Yo solía usar partimage, pero no era posible verificar la suma de comprobación de las particiones en el C2, así que cambié a partclone. Partclone puede hacer una copia de seguridad en bloque de las particiones FAT conservando los datos en los mismos offsets y, además, permite omitir el espacio vacío.
$ sudo apt-get install partclone $ sudo partclone.vfat -c -s /dev/mmcblk0p1 -O $backupDir/partition_1.imgEl "-c" especifica "clonar", "-s" es la partición de origen, que es la primera partición en nuestro caso, y "-O" es el archivo de salida, que se sobrescribirá si existe. Ten en cuenta que partclone no puede funcionar con sistemas de archivos montados y finalizará con un error. Para realizar una copia de seguridad desde un ODROID en ejecución, deberás desmontar /media/boot, realizar la copia de seguridad y volver a montarlo.
Para restaurar una partición FAT, puedes ejecutar el siguiente comando:
$ sudo partclone.restore -s $backupDir/partition_1.img -o /dev/mmcblk0p1
Desafortunadamente, PartClone no te permitirá restaurar una partición a una partición de destino más pequeña o más grande, de modo que cualquier ajuste de tamaño que quieras realizar tendrás que llevarlo a cabo tras la restauración. En realidad, puede restaurar a una partición más grande, pero necesitarás aumentarla manualmente para usar el espacio adicional.
Eopia de seguridad y restauración de particiones Ext2/3/4
Para hacer una copia de seguridad y restaurar los sistemas de archivos Ext2/3/4, necesitaremos usar una herramienta diferente llamada FSArchiver. A diferencia de PartClone, FSArchiver crea una copia de seguridad a nivel de archivo y reconstruye el sistema de archivos al restaurar. Desafortunadamente, debido a ciertas particularidades de los sistemas FAT donde los archivos de arranque de Windows deben estar en offsets específicos, el autor de fsarchiver no admite copias de seguridad de los sistemas de archivos FAT, de modo que estamos obligados a utilizar dos herramientas. Pero con la ayuda de paquetes externos, fsarchiver puede soportar otros sistemas de archivos, como XFS, ReiserFS, JFS, BTRFS y NTFS. Por lo general, realiza copias de seguridad de sistemas de archivos no montados, aunque también se puede utilizar en sistemas de archivos activos con el indicador "-A", que no seimpre funciona. FSArchiver tiene la ventaja de que puede restaurar un sistema de archivos en una partición de destino más grande o más pequeña al mismo tiempo que conserva los UUID. Para hacer una copia de seguridad de la segunda partición, puede ejecutar los siguientes comandos:
$ sudo apt-get install fsarchiver $ sudo fsarchiver -o -v -A -j 4 savefs $backupDir/partition_2.fsa /dev/mmcblk0p2El delimitador "-o" significa sobrescribir el archivo de destino si existe, "-v" muestra resultados detallados del proceso, "-A" te permite hacer una copia de seguridad de una partición montada y "-j 4" te permite usar 4 núcleos para la compresión.
Para restaurar una copia de seguridad fsa, puedes ejecutar el siguiente comando:
$ sudo fsarchiver restfs $backupDir/partition_2.fsa id=0,dest=/dev/mmcblk0p2Ten en cuenta que, puesto que FSArchiver admite múltiples particiones dentro de un archivo, necesitas especificar el ID de la partición a restaurar. En nuestro ejemplo, almacenamos solo una partición en el archivo, de modo que siempre especificaremos id=0 cuando restauremos.
SPI Flash
Las placas más modernas, como el Odroid N1, pueden presentar un chip SPI NAND Flash de baja capacidad diseñado para almacenar el gestor de arranque y el kernel, para que pueda arrancar desde la red o desde un disco SATA, sin la necesidad de una tarjeta eMMC o SD. Incluso si el diseño de este chip no se ha decidido por completo cuando escribí este documento, aún podemos hacer una copia de seguridad y restaurarla como un dispositivo de bloque con dd. Puede obtener una lista (y una descripción) de los dispositivos MTD de tu Odroid ejecutando:
$ sudo cat /proc/mtd dev: size erasesize name mtd0: 01000000 00001000 "spi32766.0"Para hacer una copia de seguridad, simplemente puedes usar:
$ sudo dd if=/dev/mtd0 of=$backupDir/flash_mtd0.bin bs=4096Para escribir en un dispositivo flash, para restaurarlo, debes borrar el bloque en el que vas a escribir. Afortunadamente, puesto que vamos a escribir todo el dispositivo, podemos borrarlo totalmente antes de escribir. Para esto necesitamos mtd-utils que proporciona flash_erase:
$ sudo apt-get install mtd-utils $ sudo flash_erase -q /dev/mtd0 0 0 $ sudo dd if=$backupDir/flash_mtd0.bin of=/dev/mtd0 bs=4096
Herramienta ODROID backup
Ahora que sabes cómo hacer las cosas manualmente, tal vez te estés preguntando por qué no son más simples las tareas de copia de seguridad y restauración, simplemente seleccionando y haciendo clic. Estoy de acuerdo en que nadie tiene tiempo para recordar todos los argumentos de línea de comando de varios comandos, así que he montado una GUI rudimentaria que te puede ayudar con el proceso de respaldo y restauración.
La herramienta en cuestión se llama descriptivamente "odroid-backup". Está escrita en Perl y usa zenity y dialog para montar una GUI rudimentaria, porque soy demasiado viejo para aprender Python. Para instalar la herramienta, puedes descargarla de mi repositorio GitHub:
$ sudo wget -O /usr/local/bin/odroid-backup.pl https://raw.githubusercontent.com/mad-ady/odroid-backup/master/odroid-backup.pl $ sudo chmod a+x /usr/local/bin/odroid-backup.plEl script depende de un puñado de módulos Perl no estándar, así como de algunas utilidades de Linux. Cuando la ejecutes por primera vez mostrará una lista de las dependencias que faltan y las formas de solucionarlo. Para instalar todas las dependencias al mismo tiempo, ejecuta lo siguiente:
$ sudo apt-get install libui-dialog-perl zenity dialog libnumber-bytes-human-perl libjson-perl sfdisk fsarchiver udev util-linux coreutils partclone parted mtd-utilsEl script está diseñado para ejecutarse en sistemas Linux, como un PC al que conectas una tarjeta SD o un módulo eMMC a través de un adaptador USB, o directamente en el ODROID (lo siento por los fanáticos de Windows). Además, el script creará ventanas gráficas si detecta que estás ejecutando una sesión X11, o recurrirá a ncurses (pantalla) si estás conectado a través de ssh o terminal. Puedes forzarlo manualmente con la opción -text.
Para realizar una copia de seguridad, inicia la herramienta en un terminal y selecciona "Backup partitions", luego selecciona OK (1):
$ sudo odroid-backup.plSe te mostrará una lista de unidades desmontables en tu sistema. Puedes iniciar el programa con el delimitador -a para mostrar todas las unidades, que es el caso cuando se ejecuta directamente en el ODROID, puesto que eMMC y SD aparecen como no extraíbles. Selecciona una y haz clic en OK (2). A continuación, se mostrará una lista con todas las particiones en esa unidad. Selecciona las que deseas respaldar (3). Después, deberás seleccionar un directorio donde guardar las copias de seguridad. Lo mejor es tener un directorio vacio (4). Presiona OK, y la copia de seguridad comenzará con una barra de progreso básica que le hará compañía (5). Cuando finalice la copia de seguridad, aparecerá una ventana con los resultados de la copia de seguridad y los posibles errores (6). Los archivos de copia de seguridad tienen la misma designación utilizada en este artículo. Para hacer una copia de seguridad de un NAND Flash necesitas volver a ejecutar la herramienta y seleccionarla desde los discos disponibles. Puede guardar el archivo resultante en el mismo directorio que las copias de seguridad de la partición.
Para realizar una restauración, inicia la herramienta en un terminal, selecciona "Restore partitions", luego selecciona OK (1):
$ sudo odroid-backup.plDeberás seleccionar el directorio que contiene tus valiosas copias de seguridad y seleccionar OK (2). En la ventana resultante, selecciona qué particiones deseas restaurar desde la copia de seguridad y selecciona OK (3). Ten en cuenta que las particiones se restauran en el mismo orden en el que estaban en el disco original, lo que significa que la partición 1 será la primera partición, y así sucesivamente. En la última ventana, se te preguntará en qué unidad deseas restaurar los datos (4). Disfruta viendo avanzar la barra de progreso (5), y al finalizar aparecerá una ventana de estado con los resultados de la restauración (6). Tambien se guarda un archivo log en /var/log/odroid-backup.log.
Limitaciones conocidas
Si realizas una copia de seguridad de un eMMC para XU3/4, los sectores ocultos (/ dev/mmcblk0boot0, /dev/mmcblk0boot1) no se copian ni se restauran. Estos bloques contienen partes del cargador UBoot. Al restaurar una copia de seguridad en una tarjeta SD o en un nuevo eMMC, la placa puede arrancar con una versión anterior de UBoot (almacenada antes de la primera partición). Como el resultado que el entorno de UBoot puede estar incompleto (por ejemplo, no hay $ {board_name} establecido), y el arranque puede ser diferente de lo normal (puede que falte la red). Una vez que arranques, se recomienda que reinstales uboot con este comando en la nueva tarjeta:
$ sudo apt-get install --reinstall ubootComo cabría de esperar, ningún software está libre de errores, pero con algo de suerte este script de seis pasos tendrá sus aplicaciones. Este script tiene algunas deficiencias, como que las ventanas de zenity no siempre muestran el texto de la instrucción, así que agregué la barra de título. Tampoco hay validación de las copias de seguridad o restauraciones. Deberás revisar el registro para verificar que la operación de copia de seguridad o restauración se haya completado correctamente. Otra limitación es que las particiones FAT deben desmontarse manualmente antes de hacer la copia de seguridad, aunque particiones Ext2/3/4 puede respaldarse estando activadas. Finalmente, la utilidad sfdisk en Ubuntu 14.04 no es compatible con JSON, de modo que no funcionará, aunque puedo agregar soporte si fuera necesario. El programa fue probado respaldando y restaurando varias imágenes oficiales de Hardkernel Linux y Android, así como imágenes de triple arranque, y hasta ahora todo parece funcionar. Las ideas para mejorar y los parches son bienvenidos, como siempre, en el hilo de soporte en http://bit.ly/2bEyFzl.
Be the first to comment