Script desatendido para eliminar ficheros antiguos de un servidor ftp

Hace ya un tiempo que dejamos por aquí el “esqueleto” de un script para realizar una conexión y transferencia desatendida a un servidor ftp. La finalidad del mismo era automatizar los backups en nuestro hosting cuando lo que nos proporcionan para ello es este medio. Auxiliar a este tenía uno que eliminaba los backups antiguos, pero nunca llegué a estar demasiado satisfecho de él. Hace poco buscando mejorarlo vi una solución maravillosamente elegante en stackoverflow. El script original es este:

#!/bin/bash
# get a list of files and dates from ftp and remove files older than ndays
ftpsite="ftp.yourserver.com"
ftpuser="loginusername"
ftppass="password"
putdir="/public_ftp/admin/logs"

ndays=7

# work out our cutoff date
MM=`date --date="$ndays days ago" +%b`
DD=`date --date="$ndays days ago" +%d`

echo removing files older than $MM $DD

# get directory listing from remote source
listing=`ftp -i -n $ftpsite <<EOMYF 
user $ftpuser $ftppass
binary
cd $putdir
ls
quit
EOMYF
`
lista=( $listing )

# loop over our files
for ((FNO=0; FNO<${#lista[@]}; FNO+=9));do
  # month (element 5), day (element 6) and filename (element 8)
  #echo Date ${lista[`expr $FNO+5`]} ${lista[`expr $FNO+6`]}          File: ${lista[`expr $FNO+8`]}

  # check the date stamp
  if [ ${lista[`expr $FNO+5`]}=$MM ];
  then
    if [[ ${lista[`expr $FNO+6`]} -lt $DD ]];
    then
      # Remove this file
      echo "Removing ${lista[`expr $FNO+8`]}"
      ftp -i -n $ftpsite <<EOMYF2 
      user $ftpuser $ftppass
      binary
      cd $putdir
      delete ${lista[`expr $FNO+8`]}
      quit
EOMYF2

    fi
  fi
done

Por comentarlo un poco y “ganarnos el pan”, el script tiene tres bloques: el primero de definición de variables que tendrás que personalizar con tus datos (hasta la línea 8 incluida), el segundo en el que se realiza una conexión con el servidor y se obtiene un listado de todos los ficheros que están en el directorio que indicamos (hasta la línea 25) y por último un tercer bloque en el que se realiza el borrado propiamente dicho.

En el primer bloque la variable ndays en la línea 8 define la máxima antigüedad de los ficheros que no se eliminaran (7 días en este caso) y la variable putdir en la 6 el directorio del servidor ftp donde dejamos los archivos. Si, como yo, dejas los backups directamente en el raiz del servidor ftp puedes eliminar (o comentar) las líneas 6, 20 y 42

En el segundo bloque, la línea 14 indica la fecha límite de los ficheros que se conservaran. Todos los anteriores a esta se eliminarán. Si no quieres que aparezca en la salida puedes eliminarla o comentarla.

En el tercer bloque, si quieres hacer pruebas de que el script funciona antes de lanzarlo en modo real, puedes comentar la línea 43. Esto te mostrará en la consola los ficheros que se eliminarían pero no te los borrará realmente con lo cual podrás comprobar que el script hace lo que realmente necesitas. La línea 38 es la que te muestra el fichero que va a borrarse. Puedes eliminarla o comentarla también cuando ya no te interese. Por último, la línea 30 que aparece comentada muestra un listado de todos los ficheros del servidor ftp antes de realizar el borrado. Puedes descomentarla también para evaluar si está trabajando de forma correcta.

Chuletillas (y XXXXIV) – Liberar espacio en un servidor FTP lleno

chuleta ¿Te has quedado sin espacio alguna vez en un servidor FTP? Si te ha pasado te habrás llevado la sorpresa de que no puedes eliminar ningún archivo para liberar espacio porque si el servidor FTP está completamente lleno no es posible. Si, si, parece de broma pero así es:

mdelete *.tar.gz
550 Could not mdelete *.tar.gz: No space left on device

La solución es sencilla, pero hay que saberla 😉 . Basta con enviar al servidor FTP un fichero vacío con 0 bytes con el mismo nombre que uno de los que queremos eliminar para liberar espacio. La operación de sustitución si se llevará a cabo correctamente y a partir de ahí tendremos ya espacio para hacer un borrado convencional.

Script desatendido de conexión a un servidor FTP

Al contratar espacio de backup en la mayoría de las empresas de hosting la opción más habitual sigue siendo a través de FTP. Para automatizar las copias de forma desatendida necesitamos programar estas, habitualmente lanzando un script a través de cron. Si buscas un modelo para construir el tuyo puedes hacerlo a partir de este:

#!/bin/sh

HOST='ip_del_ftp_server'
USER='nombre_de_usuario'
PASSWD='password'

ftp -n -i $HOST <<END_SCRIPT
quote USER $USER
quote PASS $PASSWD
cd /file_backups
lcd /home/administrador/file_backups
mput *
cd /mysql_backups
lcd /home/administrador/mysql_backups
mput *
quit
END_SCRIPT
exit 0

El script supone que ya tenemos los ficheros que queremos copiar en dos directorios locales: /home/adminstrador/file_backups y /home/administrador/mysql_backups. Haremos la copia en dos directorios del servidor ftp que se llaman /file_backups y mysql_backups. Los parámetros -n y -i de la conexión al servidor desactivan, respectivamente, el autologin y el modo interactivo (para evitar que el servidor ftp nos pida confirmación en cada operación de copia).

Backups y recuperación de datos en PYMEs

Una buena ración de estadísticas para preocuparse un poco…
especiales Según un reciente estudio realizado entre SMBs (“Small and Medium Business”, el nombre que reciben nuestras PYMES en el mundo anglosajón) de Estados Unidos, Francia, Alemania y Reino Unido por una importante empresa del sector de la virtualización, el 85% de los interrogados tenían problemas con el coste de sus soluciones de backup, el 83% con la capacidad o el espacio de almacenamiento requerido por las mismas y el 80% con la complejidad técnica necesaria para su uso.

El estudio no tiene desperdicio y hay muchas otras cifras interesantes en él. A veces, cuentan, recuperar un simple correo electrónico borrado puede llevar hasta 12 horas, el 17% de las recuperaciones de datos que se realizan presentan algún tipo de problema o error y hasta el 55% de las empresas está considerando cambiar sus métodos de backup para el año que entra.

No conozco ningún estudio similar en nuestro país, pero lo que he visto en las PYMEs (y también en alguna gran empresa) en las que he tenido algo que ver en los últimos años es similar a lo que se cuenta aquí. O, incluso, peor. Lo que me sigue sorprendiendo es la desidia a implementar soluciones robustas en este terreno cuando todos sabemos que los discos duros fallan (¡y mucho!), pero sobre todo que las personas cometemos errores y, más a menudo de lo que nos gustaría, borramos archivos por error. O de forma malintencionada. Mirad, si no, lo que ha ocurrido en la UGT hace bien poco 😉

De lo segundo es bastante difícil conseguir datos fiables, pero de lo primero hay suficientes números como para echarse a temblar. El tiempo de vida medio de un disco duro en un entorno empresarial se estima en entre tres y cinco años. Los estudios realizados por Google dicen que a partir del segundo año la probabilidad anualizada de error en un disco se dispara al 8% y se mantiene entre este valor y el 10% en los tres años siguientes. Los estudios de ExtremeTech indican un porcentaje menor de errores en el segundo año pero los disparan a cerca del 12% a partir del tercero. Y ¿son más fiables los nuevos discos SSD? Es difícil comparar una tecnología con poco más de cinco años con otra de más de 50, pero los pocos estudios que se han hecho por el momento indican que el incremento en la fiabilidad de esta tecnología es escaso o inexistente.

Las técnicas de backup y de recuperación de datos son, hoy en día, inexcusables en un entorno informático y, si me apuran, en el personal. Cualquier empresa que se precie debería de tomarse ambas cosas muy en serio y asegurarse de que usa mecanismos acordes a lo que trata de proteger. Porque luego lamentarse es gratis, pero no sirve ya de nada.

Referencias:

Consolidar y centralizar las copias de seguridad

En muchas empresas de tamaño medio que he conocido no existe una estrategia de backups centralizado. Normalmente todos los servidores se adquieren con algún tipo de dispositivo de backup (habitualmente una unidad de cintas DAT, DLT o LTO) y los procedimientos de salvaguarda se gestionan de forma independiente en cada una de estas máquinas a veces gestionados por distintas personas e incluso con diferentes criterios.

Se trata de una práctica que es soportable cuando estamos hablando de dos o, a lo sumo, tres servidores, pero a medida que el número de estos va creciendo la situación se convierte en algo intratable, se multiplican los puntos de fallos, las tareas de comprobación… mientras que con una pequeña inversión (que, en realidad no es tal si contamos lo que nos ahorramos en dispositivos independientes de backup en cada servidor, licencias si procede, soportes, operación y mantenimiento, etc.) es realmente fácil centralizar los backups creando, además, un sistema mucho más robusto y con más niveles de seguridad. Ni que decir tiene, además, que centralizar las copias es también mucho más práctico de cara a desarrollar y cumplir una política de seguridad interna.

Lo primero que necesitamos es una unidad de almacenamiento NAS o SAN de la capacidad adecuada. Para que os hagais una idea de los costes, un dispositivo con 2 Teras de capacidad y RAID5 por hardware puede salir por entre 3.000 y 4.000 euros. Esta máquina será nuestro primer nivel de backups y sobre ella programaremos una copia diaria de toda la información que necesitamos salvaguardar. Para ello utilizaremos diferentes estrategias. Los archivos de datos los copiaremos con alguna utilidad desde línea de comandos y con ejecución programada a la hora que convengamos una vez que la actividad de la empresa haya finalizado si es posible o a las horas de menor actividad si no hay más remedio. En el mundo de microsoft tenemos robocopy o xxcopy y la programación la haremos mediante el scheduler. En GNU/Linux tenemos rsync o rdiff y cron. En realidad sirve cualquier herramienta con la que nos sintamos cómodos, que respete los atributos de origen de los archivos y que nos permita una copia incremental de los mismos.

Las copias de la información del registro de windows (si las necesitamos) las programaremos desde el ntbackup sobre un directorio local de la máquina que luego será replicado en nuestro NAS con el procedimiento anterior. Para las copias en caliente de las bases de datos seguiremos un procedimiento similar: una primera copia en local mediante la utilidad de que disponga nuestro gestor de bases de datos que luego será replicada.

Ni que decir tiene que lo más importante en todo este proceso es la sincronización: primero las copias a local de los archivos que necesitan un tratamiento especial (registros, bases de datos, etc.) y luego la copia de estos archivos y del resto de información que necesitemos a nuestro dispositivo NAS o SAN. No es tan complicado como parece: se trata de hacer un par de pruebas y ajustar los tiempos.

Yo suelo hacer esta copia sin compresión de ningún tipo. Por dos motivos: porque facilita y agiliza muchísimo la recuperación de las copias más frecuentes (los administradores sabemos que en un alto porcentaje de los casos en los que tenemos que recurrir a un backup es porque un usuario, por torpeza o descuido, necesita volver a la versión de ayer de algún documento) y porque, si así lo queremos, podemos darle a los usuarios acceso de lectura a este primer nivel para que sean ellos mismos los que se restauren las copias en caso de necesidad y así aligerar el proceso y descargar de trabajo a los técnicos.

Para nuestro segundo nivel necesitamos un ‘autoloader’ o robot de backups. Una unidad con capacidad para 16 cintas LTO-3 y unos 12 Teras comprimidos puede costarnos en torno a los 8.000 euros. Con ella estableceremos un programa de backups diario adecuado a nuestras necesidades con la ventaja de que sólo tendremos que hacer copias de un único dispositivo y si usamos software propietario para ello (Symantec Backup Exec, antes Veritas, por ejemplo) no necesitaremos más que una licencia. En cuanto al programa de backups, sobre gustos los colores. Yo suelo programar una copia completa todos los viernes que mantengo durante cuatro semanas y copias diferenciales de lunes a viernes que se sobreescriben cada semana. Habrá que sincronizar el arranque de este backup una vez que haya finalizado la copia de cada uno de los servidores independientes.

Para rizar el rizo podemos retirar la copia completa del último viernes de cada mes de forma que podamos mantener un histórico mensual de todo el activo de la empresa (no os podeis ni imaginar lo útil que es cuando el director de no-se-que proyecto se da cuenta de que le ha salido un champiñón igual al de hace dos años y que ha borrado toda la documentación del mismo) y, si queremos gastarnos un poco más de dinero, conservar estas copias en una caja ignífuga. Un armario ignífugo de seguridad de unos 100 litros de capacidad (no veais la cantidad de cintas que caben ahí ;-)) y que pase el test NT Fire 017-120D (2 horas a temperaturas de 1045 grados centígrados externos manteniendo menos de 54 internos) puede costarnos alrededor de 1.000 o 1.500 euros.