No sé qué fue de aquella marca que hacía unos móviles a prueba de bombas. En mala hora elegí semejante CACHARRO.
1- Cuando intento escuchar la radio, el teléfono se reinicia. Otras aplicaciones me bloquean el móvil (la pantalla aparece llena de puntos, y tengo que quitar la batería)
2- La memoria del teléfono se llena misteriosamente, y el teléfono se BLOQUEA. Ahora mismo no puedo ni enviar SMS.
3- Falta de aplicaciones para Symbian. Todo sale para Android o iOS.
4- Instalar What's app bloquea mi teléfono. Instalar "Radio por internet" bloquea mi teléfono. Realmente, ya no sé qué puedo hacer con el teléfono para que NO se bloquee. Imagino que todo estará relacionado con la porquería de memoria interna que le han puesto al cacharro.
5- No tiene un botón externo para la camara, y no tiene flash.
6- No trae "lápiz" para manejar la pantalla táctil con precisión. El resultado es que es una tortura usar cualquier aplicación un poco delicada, como el navegador web.
7- Y la cosa sigue, y sigue y sigue...
Quiero aclarar que tengo el software actualizado a la última versión. También he seguido los asistentes para liberar memoria (de hecho, ahora tengo dos mensajes SMS y una agenda de menos de 100 contactos) y las páginas de soporte de la web oficial de Nokia.
Así que si estás en comprate este engendro, ¡huye insensato!
viernes, 6 de abril de 2012
martes, 3 de abril de 2012
SSH: Eliminando claves erróneas del fichero known_hosts
Otro recordatorio para mi memoria de pez.
Debian almacena las claves públicas de los hosts a los que se conecta en el fichero
/home/usuario/.ssh/known_hosts
En ocasiones, la clave pública de un ordenador puede cambiar. Por ejemplo, porque hayamos trasladado el servidor. En esos casos, SSH se negará a conectarse al servidor nuevo porque su clave pública actual no coincidirá con la antigua. Lo hará con un mensaje apocalíptico:
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@ WARNING: POSSIBLE DNS SPOOFING DETECTED! @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
The RSA host key for ftp.xxxxx.es has changed, and the key for the corresponding IP address x.x.x.x is unchanged. This could either mean that DNS SPOOFING is happening or the IP address for the host
and its host key have changed at the same time.
Offending key for IP in /home/jose/.ssh/known_hosts:18
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@ WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
Someone could be eavesdropping on you right now (man-in-the-middle attack)!
It is also possible that the RSA host key has just been changed.
The fingerprint for the RSA key sent by the remote host is
6f:16:ff:ce:2f:30:15:86:d8:69:dd:6c:c7:fe:21:0c.
Please contact your system administrator.
Add correct host key in /home/jose/.ssh/known_hosts to get rid of this message.
Offending key in /home/jose/.ssh/known_hosts:11
RSA host key for ftp.xxxxx.es has changed and you have requested strict checking.
Host key verification failed.
lost connection
Bueno, pues hay tres formas de arreglar ésto:
a- Configurando SSH para que no haga un chequeo estricto de claves. No es aconsejable, por motivos de seguridad.
b- Borrando el fichero known_hosts. Tampoco es aconsejable por motivos de seguridad, y encima cada vez que te conectes a tus servidores te volverá a preguntar si quieres confiar en la clave pública. Un coñazo.
c- Usar ssh-keygen para eliminar sólo la clave problemática en el fichero known_hosts :
jose@jose:~$ ssh-keygen -R "ftp.xxxxx.es"
/home/jose/.ssh/known_hosts updated.
Original contents retained as /home/jose/.ssh/known_hosts.old
Debian almacena las claves públicas de los hosts a los que se conecta en el fichero
/home/usuario/.ssh/known_hosts
En ocasiones, la clave pública de un ordenador puede cambiar. Por ejemplo, porque hayamos trasladado el servidor. En esos casos, SSH se negará a conectarse al servidor nuevo porque su clave pública actual no coincidirá con la antigua. Lo hará con un mensaje apocalíptico:
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@ WARNING: POSSIBLE DNS SPOOFING DETECTED! @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
The RSA host key for ftp.xxxxx.es has changed, and the key for the corresponding IP address x.x.x.x is unchanged. This could either mean that DNS SPOOFING is happening or the IP address for the host
and its host key have changed at the same time.
Offending key for IP in /home/jose/.ssh/known_hosts:18
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@ WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
Someone could be eavesdropping on you right now (man-in-the-middle attack)!
It is also possible that the RSA host key has just been changed.
The fingerprint for the RSA key sent by the remote host is
6f:16:ff:ce:2f:30:15:86:d8:69:dd:6c:c7:fe:21:0c.
Please contact your system administrator.
Add correct host key in /home/jose/.ssh/known_hosts to get rid of this message.
Offending key in /home/jose/.ssh/known_hosts:11
RSA host key for ftp.xxxxx.es has changed and you have requested strict checking.
Host key verification failed.
lost connection
Bueno, pues hay tres formas de arreglar ésto:
a- Configurando SSH para que no haga un chequeo estricto de claves. No es aconsejable, por motivos de seguridad.
b- Borrando el fichero known_hosts. Tampoco es aconsejable por motivos de seguridad, y encima cada vez que te conectes a tus servidores te volverá a preguntar si quieres confiar en la clave pública. Un coñazo.
c- Usar ssh-keygen para eliminar sólo la clave problemática en el fichero known_hosts :
jose@jose:~$ ssh-keygen -R "ftp.xxxxx.es"
/home/jose/.ssh/known_hosts updated.
Original contents retained as /home/jose/.ssh/known_hosts.old
Fin del problema.
jueves, 22 de marzo de 2012
Sirviendo actualizaciones ClickOnce desde un servidor Apache.
Como programador, estoy encantado con el sistema "ClickOnce" de actualización de Microsoft. Permite instalar y distribuir actualizaciones de forma práctica y rápida.
Como administrador de sistemas, soy un firme partidario del servidor web Apache, por razones técnicas, económicas (sin coste de licencias) y prácticas (es el servidor web más utilizado en Internet).
Pero independientemente de las opiniones de cada uno, a veces hay que hacer funcionar ClickOnce sobre Apache, y punto pelota :) Veamos como.
Lo primero, aclarar que sólo he conseguido que funcione para actualizar, no para instalar por primera vez el programa. Por eso el artículo se llama "sirviendo actualizaciones". Yo suelo hacer la instalación manualmente en los equipos de los clientes, y luego utilizo Apache para distribuir las actualizaciones, que suele ser el 90% del trabajo.
En primer lugar, hay que preparar el alojamiento web para nuestros ficheros. Puedes hacerlo mediante un host virtual, a través de un puerto diferente o de un subdirectorio dentro de tu sitio web. En mi caso, utilizo un subdirectorio, por lo que los ficheros son accesibles desde:
http://www.miweb.com/aplicacion
Mientras preparas el alojamiento, ten en cuenta las restricciones de seguridad que quieras aplicar. Creo que es aconsejable, al menos, limitar las IPs desde las que se pueden conectar a las IPs del cliente. En fin, haz lo que quieras. En el manual de Apache viene todo muy bien explicadito :)
En segundo lugar, hay que preparar la aplicación para que se actualice a través de web.
En Visual Studio 2010, saca las propiedades de tu proyecto y vete a la solapa de Publicar. En la casilla Ubicación de la carpeta de publicación debes poner una carpeta de tu ordenador, por ejemplo "C:\publicaciones".
En el botón de Actualizaciones, selecciona "la aplicación debe buscar actualizaciones", y en la "Ubicación de actualizaciones" pon el alojamiento que preparaste en el primer paso. En mi caso, http://www.miweb.com/aplicacion El resto de parámetros ponlos como quieras. Yo prefiero que las actualizaciones se busquen antes de ejecutar la aplicación, pero eso ya es cosa de cada uno.
Finalmente, quedan los pasos que hay que seguir cada vez que quieras liberar una actualización.
En primer lugar, evidentemente, debes generar los ficheros de publicación. En las propiedades del proyecto, selecciona "Publicar ahora". En nuestro ejemplo, eso generará los ficheros de actualización en la carpeta C:\publicaciones
Copia todo el contenido de "C:\publicaciones" a tu alojamiento web (probablemente algo como /var/www/miweb/aplicacion o /home/usuario/public_html/aplicacion).
Ahora, debes asegurarte de que todos los ficheros tienen activado el permiso +r para todos los usuarios. Si puedes conectarte por SSH, la orden es:
find . -exec chmod ugo+r \{\} \;
Si no puedes conectarte por SSH, usa tu cliente de FTP para cambiar los permisos.
Finalmente, debes activar el permiso +x a todos los directorios. Por SSH, se haría:
find . -type d -exec chmod ugo+x \{\} \;
o usa tu cliente FTP.
Debes cambiar los permisos cada vez que subas una actualización, o lo más probable es que los clientes no se actualicen.
Pues eso es todo. Happy ClickOnce.
Como administrador de sistemas, soy un firme partidario del servidor web Apache, por razones técnicas, económicas (sin coste de licencias) y prácticas (es el servidor web más utilizado en Internet).
Pero independientemente de las opiniones de cada uno, a veces hay que hacer funcionar ClickOnce sobre Apache, y punto pelota :) Veamos como.
Lo primero, aclarar que sólo he conseguido que funcione para actualizar, no para instalar por primera vez el programa. Por eso el artículo se llama "sirviendo actualizaciones". Yo suelo hacer la instalación manualmente en los equipos de los clientes, y luego utilizo Apache para distribuir las actualizaciones, que suele ser el 90% del trabajo.
En primer lugar, hay que preparar el alojamiento web para nuestros ficheros. Puedes hacerlo mediante un host virtual, a través de un puerto diferente o de un subdirectorio dentro de tu sitio web. En mi caso, utilizo un subdirectorio, por lo que los ficheros son accesibles desde:
http://www.miweb.com/aplicacion
Mientras preparas el alojamiento, ten en cuenta las restricciones de seguridad que quieras aplicar. Creo que es aconsejable, al menos, limitar las IPs desde las que se pueden conectar a las IPs del cliente. En fin, haz lo que quieras. En el manual de Apache viene todo muy bien explicadito :)
En segundo lugar, hay que preparar la aplicación para que se actualice a través de web.
En Visual Studio 2010, saca las propiedades de tu proyecto y vete a la solapa de Publicar. En la casilla Ubicación de la carpeta de publicación debes poner una carpeta de tu ordenador, por ejemplo "C:\publicaciones".
En el botón de Actualizaciones, selecciona "la aplicación debe buscar actualizaciones", y en la "Ubicación de actualizaciones" pon el alojamiento que preparaste en el primer paso. En mi caso, http://www.miweb.com/aplicacion El resto de parámetros ponlos como quieras. Yo prefiero que las actualizaciones se busquen antes de ejecutar la aplicación, pero eso ya es cosa de cada uno.
Finalmente, quedan los pasos que hay que seguir cada vez que quieras liberar una actualización.
En primer lugar, evidentemente, debes generar los ficheros de publicación. En las propiedades del proyecto, selecciona "Publicar ahora". En nuestro ejemplo, eso generará los ficheros de actualización en la carpeta C:\publicaciones
Copia todo el contenido de "C:\publicaciones" a tu alojamiento web (probablemente algo como /var/www/miweb/aplicacion o /home/usuario/public_html/aplicacion).
Ahora, debes asegurarte de que todos los ficheros tienen activado el permiso +r para todos los usuarios. Si puedes conectarte por SSH, la orden es:
find . -exec chmod ugo+r \{\} \;
Si no puedes conectarte por SSH, usa tu cliente de FTP para cambiar los permisos.
Finalmente, debes activar el permiso +x a todos los directorios. Por SSH, se haría:
find . -type d -exec chmod ugo+x \{\} \;
o usa tu cliente FTP.
Debes cambiar los permisos cada vez que subas una actualización, o lo más probable es que los clientes no se actualicen.
Pues eso es todo. Happy ClickOnce.
viernes, 17 de febrero de 2012
Backups usando RSYNC
Introducción.
rsync es una de esas pequeñas maravillas en el arsenal de los administradores de Linux. Aunque se le puede dar muchos usos, aquí voy a centrarme en las copias de seguridad.
En el trabajo, tengo varios terabytes de información repartidos en servidores de la red local e Internet. He probado varias soluciones de backup. Algunas me daban problemas con los nombres de archivo, otras no podían conectarse a los servidores externos o no funcionaban en Linux o en Windows. A la mayoría les costaba manejar esa cantidad de información, y podían tardar días en actualizar la copia de seguridad.
rsync es la solución más eficiente que he encontrado. En una o dos horas, es capaz de mantener la copia de seguridad actualizada, así que lo que antes eran copias de seguridad semanales, ahora son diarias. Ahorra ancho de banda al trasferir ficheros por Internet, y a veces es capaz de actualizar sólo la parte del fichero que ha cambiado. Encima gratuito, claro.
Vamos a ver cómo funciona.
Instalación.
apt-get install rsync
Uso básico.
El ejemplo más simple de uso de rsync sería:
rsync -av /home/jose/datos /mnt/disco_usb
Eso copiaría el directorio /home/jose/datos dentro del directorio /mnt/disco_usb. El destino podría ser un sistema de ficheros montado previamente o no ... para rsync, son dos sistemas de ficheros locales.
La opción -a activa el "modo archivador", lo que significa que hará una copia recursiva lo más fiel posible al origen. La opción -v hará que imprima los nombres de los ficheros que copia.
rsync permite hacer copias entre dos sistemas de ficheros locales, o entre un sistema de ficheros local y uno remoto. Hay dos formas de conectarse a un sistema remoto: a través de SSH o conectándose a un demonio RSYNC.
Para conectarse a un demonio RSYNC, previamente hay que configurarlo.Básicamente, hay que editar el fichero rsyncd.conf en la máquina remota, y luego conectarse al módulo correspondiente.
Yo personalmente prefiero conectarme por SSH. La sintaxis es la siguiente:
rsync -avz jose@192.168.0.50:/home/jose/datos /mnt/disco_usb
La orden anterior se conectará a la máquina 192.168.0.50 con el usuario jose, pedirá una clave, y copiará /home/jose/datos a nuestra carpeta local /mnt/disco_hd
La opción -z activará la compresión de datos. Comprimir los datos ahorra ancho de banda a cambio de un mayor tiempo de procesador; es una opción útil para pasar datos a través de Internet, pero no tanto a través de una red local.
Como ya he dicho, uno de los dos sistemas de ficheros tiene que ser local. Rsync no permite, por ejemplo, copiar ficheros entre dos conexiones ssh. Sin embargo, nada te impide montar un sistema de ficheros de red (CIFS, ntfs, shfs...) y hacer copia entre ellos. Rsync considerará estos sistemas locales.
Sincronizando sistemas de ficheros.
Bueno, lo que hemos visto hasta ahora no tiene nada de novedoso ... parece que rsync es como un cp -r o un rcp.
La diferencia fundamental es que rsync no sólo copia, sino que sincroniza los dos directorios y todas sus subcarpetas. Nuestro ejemplo anterior...
rsync -avz jose@192.168.0.50:/home/jose/datos /mnt/disco_usb
... se comporta de la siguiente manera:
. Si el fichero no existe en el destino, lo copia.
. Si el fichero existe en destino y ha sido modificado en origen, lo sobreescribe.
. Si el fichero existe en destino y no ha sido modificado en origen, no hace nada.
. Si el fichero ha sido borrado en origen y existe en destino, lo deja tal cual.
La gracia está en el punto tres. La primera vez que ejecutemos la orden, rsync copiará todos los ficheros. Las siguientes veces, sólo copiará los ficheros nuevos o los que hayan sido modificados. Eso supone un ahorro tremendo de tiempo y ancho de banda.
Copias de seguridad.
Con la funcionalidad básica que hemos visto arriba podemos hacer copias de seguridad algo chapuceras. Si un fichero se modifica, las modificaciones reescribirán cualquier versión anterior. Si un fichero se borra, permanecerá indefinidamente en la copia de seguridad (que irá engordando con el tiempo). Sólo necesitamos un par de opciones más para pulir este comportamiento.
La opción --delete borra los ficheros en destino que no se encuentren en el origen. Así, cuando en el directorio de datos se borre un fichero, también desaparecerá de nuestra copia de seguridad. De esa forma, nuestra copia será una imagen exacta de nuestros datos. En general es una buena cosa, pero también queremos mantener un histórico.
Las opciones --backup y --backup-dir son las últimas que necesitamos. La primera le dice a rsync que antes de sobrescribir o borrar un fichero, debe hacer una copia de seguridad. La segunda le dice en qué directorio debe hacerla.
Ejemplo de copia de seguridad funcional.
Vamos a poner un ejemplo. Fíjate en la siguiente orden:
rsync -av --delete --backup --backup-dir=historico/cambios-`date +%d-%m-%y` admin@192.168.1.15:/share/MD0_DATA/datos /share/MD0_DATA/datos/qnap1
Cuando ejecutes esta orden en la línea de comandos, el intérprete de ordenes expandirá `date +%d-%m-%y` por la fecha actual. Es decir, si lo ejecutas el 5 de febrero, la orden que se ejecutará será
rsync -av --delete --backup --backup-dir=historico/cambios-5-2-2012 admin@192.168.1.15:/share/MD0_DATA/datos /share/MD0_DATA/datos/qnap1
... y si lo ejecutas el día 6 será
rsync -av --delete --backup --backup-dir=historico/cambios-6-2-2012 admin@192.168.1.15:/share/MD0_DATA/datos /share/MD0_DATA/datos/qnap1
Es decir, se creará un directorio de backup por cada día que ejecutes rsync.
¿Que va a hacer esta orden? Se va a conectar a la máquina 192.168.1.15 con el usuario admin, y va a sincronizar el directorio /share/MD0_DATA/datos con el directorio local /share/MD0_DATA/datos/qnap1 Exactamente se va a comportar así:
. Si el fichero no existe en el destino, lo va a copiar.
. Si el fichero existe en el destino, pero no ha sido modificado en origen, no hará nada.
. Si el fichero existe en el destino y ha sido modificado, creará una copia de seguridad en el directorio correspondiente al día y lo sobreescribirá.
. Si el fichero ha sido borrado en origen, creará una copia de seguridad en el directorio correspondiente al día y lo borrará en destino.
¿Cómo quedará nuestra copia de seguridad? Veamos...
[~] # ls /share/MD0_DATA/datos/qnap1
datos/ historico/
En el directorio datos tenemos una copia exacta de nuestros datos. Está la última versión de cada fichero, y si un fichero ha sido borrado en la carpeta de datos, habrá sido borrado de la copia de seguridad. Pero ....
[~] # ls /share/MD0_DATA/datos/qnap1/historico/
cambios-13-02-12/ cambios-16-02-12/ cambios-31-01-12/
cambios-14-02-12/ cambios-17-02-12/
cambios-15-02-12/ cambios-30-01-12/
rsync es una de esas pequeñas maravillas en el arsenal de los administradores de Linux. Aunque se le puede dar muchos usos, aquí voy a centrarme en las copias de seguridad.
En el trabajo, tengo varios terabytes de información repartidos en servidores de la red local e Internet. He probado varias soluciones de backup. Algunas me daban problemas con los nombres de archivo, otras no podían conectarse a los servidores externos o no funcionaban en Linux o en Windows. A la mayoría les costaba manejar esa cantidad de información, y podían tardar días en actualizar la copia de seguridad.
rsync es la solución más eficiente que he encontrado. En una o dos horas, es capaz de mantener la copia de seguridad actualizada, así que lo que antes eran copias de seguridad semanales, ahora son diarias. Ahorra ancho de banda al trasferir ficheros por Internet, y a veces es capaz de actualizar sólo la parte del fichero que ha cambiado. Encima gratuito, claro.
Vamos a ver cómo funciona.
Instalación.
apt-get install rsync
Uso básico.
El ejemplo más simple de uso de rsync sería:
rsync -av /home/jose/datos /mnt/disco_usb
Eso copiaría el directorio /home/jose/datos dentro del directorio /mnt/disco_usb. El destino podría ser un sistema de ficheros montado previamente o no ... para rsync, son dos sistemas de ficheros locales.
La opción -a activa el "modo archivador", lo que significa que hará una copia recursiva lo más fiel posible al origen. La opción -v hará que imprima los nombres de los ficheros que copia.
rsync permite hacer copias entre dos sistemas de ficheros locales, o entre un sistema de ficheros local y uno remoto. Hay dos formas de conectarse a un sistema remoto: a través de SSH o conectándose a un demonio RSYNC.
Para conectarse a un demonio RSYNC, previamente hay que configurarlo.Básicamente, hay que editar el fichero rsyncd.conf en la máquina remota, y luego conectarse al módulo correspondiente.
Yo personalmente prefiero conectarme por SSH. La sintaxis es la siguiente:
rsync -avz jose@192.168.0.50:/home/jose/datos /mnt/disco_usb
La orden anterior se conectará a la máquina 192.168.0.50 con el usuario jose, pedirá una clave, y copiará /home/jose/datos a nuestra carpeta local /mnt/disco_hd
La opción -z activará la compresión de datos. Comprimir los datos ahorra ancho de banda a cambio de un mayor tiempo de procesador; es una opción útil para pasar datos a través de Internet, pero no tanto a través de una red local.
Como ya he dicho, uno de los dos sistemas de ficheros tiene que ser local. Rsync no permite, por ejemplo, copiar ficheros entre dos conexiones ssh. Sin embargo, nada te impide montar un sistema de ficheros de red (CIFS, ntfs, shfs...) y hacer copia entre ellos. Rsync considerará estos sistemas locales.
Sincronizando sistemas de ficheros.
Bueno, lo que hemos visto hasta ahora no tiene nada de novedoso ... parece que rsync es como un cp -r o un rcp.
La diferencia fundamental es que rsync no sólo copia, sino que sincroniza los dos directorios y todas sus subcarpetas. Nuestro ejemplo anterior...
rsync -avz jose@192.168.0.50:/home/jose/datos /mnt/disco_usb
... se comporta de la siguiente manera:
. Si el fichero no existe en el destino, lo copia.
. Si el fichero existe en destino y ha sido modificado en origen, lo sobreescribe.
. Si el fichero existe en destino y no ha sido modificado en origen, no hace nada.
. Si el fichero ha sido borrado en origen y existe en destino, lo deja tal cual.
La gracia está en el punto tres. La primera vez que ejecutemos la orden, rsync copiará todos los ficheros. Las siguientes veces, sólo copiará los ficheros nuevos o los que hayan sido modificados. Eso supone un ahorro tremendo de tiempo y ancho de banda.
Copias de seguridad.
Con la funcionalidad básica que hemos visto arriba podemos hacer copias de seguridad algo chapuceras. Si un fichero se modifica, las modificaciones reescribirán cualquier versión anterior. Si un fichero se borra, permanecerá indefinidamente en la copia de seguridad (que irá engordando con el tiempo). Sólo necesitamos un par de opciones más para pulir este comportamiento.
La opción --delete borra los ficheros en destino que no se encuentren en el origen. Así, cuando en el directorio de datos se borre un fichero, también desaparecerá de nuestra copia de seguridad. De esa forma, nuestra copia será una imagen exacta de nuestros datos. En general es una buena cosa, pero también queremos mantener un histórico.
Las opciones --backup y --backup-dir son las últimas que necesitamos. La primera le dice a rsync que antes de sobrescribir o borrar un fichero, debe hacer una copia de seguridad. La segunda le dice en qué directorio debe hacerla.
Ejemplo de copia de seguridad funcional.
Vamos a poner un ejemplo. Fíjate en la siguiente orden:
rsync -av --delete --backup --backup-dir=historico/cambios-`date +%d-%m-%y` admin@192.168.1.15:/share/MD0_DATA/datos /share/MD0_DATA/datos/qnap1
Cuando ejecutes esta orden en la línea de comandos, el intérprete de ordenes expandirá `date +%d-%m-%y` por la fecha actual. Es decir, si lo ejecutas el 5 de febrero, la orden que se ejecutará será
rsync -av --delete --backup --backup-dir=historico/cambios-5-2-2012 admin@192.168.1.15:/share/MD0_DATA/datos /share/MD0_DATA/datos/qnap1
... y si lo ejecutas el día 6 será
rsync -av --delete --backup --backup-dir=historico/cambios-6-2-2012 admin@192.168.1.15:/share/MD0_DATA/datos /share/MD0_DATA/datos/qnap1
Es decir, se creará un directorio de backup por cada día que ejecutes rsync.
¿Que va a hacer esta orden? Se va a conectar a la máquina 192.168.1.15 con el usuario admin, y va a sincronizar el directorio /share/MD0_DATA/datos con el directorio local /share/MD0_DATA/datos/qnap1 Exactamente se va a comportar así:
. Si el fichero no existe en el destino, lo va a copiar.
. Si el fichero existe en el destino, pero no ha sido modificado en origen, no hará nada.
. Si el fichero existe en el destino y ha sido modificado, creará una copia de seguridad en el directorio correspondiente al día y lo sobreescribirá.
. Si el fichero ha sido borrado en origen, creará una copia de seguridad en el directorio correspondiente al día y lo borrará en destino.
¿Cómo quedará nuestra copia de seguridad? Veamos...
[~] # ls /share/MD0_DATA/datos/qnap1
datos/ historico/
[~] # ls /share/MD0_DATA/datos/qnap1/historico/
cambios-13-02-12/ cambios-16-02-12/ cambios-31-01-12/
cambios-14-02-12/ cambios-17-02-12/
cambios-15-02-12/ cambios-30-01-12/
¡Ajam! Aquí está nuestro histórico. En estas carpetas están todos los ficheros borrados o modificados. Si un fichero se cambió el día 17, tendremos una copia actual en la carpeta datos, y una copia de la versión anterior en historico/cambios-16-02-12 Si un fichero fue borrado, desaparecerá de la carpeta de datos, pero tendremos nuestro respaldo en la carpeta del histórico correspondiente.
Dependiendo del espacio de almacenamiento disponible tendremos que ir borrando carpetas históricas. Una simple orden find puede hacer el trabajo.
Espero que el artículo te resulte útil :)
viernes, 18 de noviembre de 2011
C#: Ficheros y rutas de trabajo temporales en Windows.
Ésto lo escribo más como un recordatorio para mi mismo que otra cosa.
Para obtener el directorio de trabajo temporal en Windows, puede usarse la siguiente función:
Path.GetTempPath()
Esta función crea un fichero vacío con un nombre único , y te devuelve su nombre:
Path.GetTempFileName()
Para obtener el directorio de trabajo temporal en Windows, puede usarse la siguiente función:
Path.GetTempPath()
Esta función crea un fichero vacío con un nombre único , y te devuelve su nombre:
Path.GetTempFileName()
Suscribirse a:
Entradas (Atom)