Revisión de mi estrategia de backup

Desde hace varios años tengo implementado un sistema de backup automático para mis datos importantes. Pero hechos recientes me han empujado a revisar mi estrategia, encontrando dos puntos a tener muy en cuenta:

  • Mi sistema de backup tenía importantes carencias
  • Mis necesidades actuales han cambiado

Nuevos tiempos requieren nuevos planteamientos, así que aproveché la caída de uno de los discos del NAS para rediseñar e implementar un nuevo sistema de backup de datos.

Como consejo para cualquiera que esté buscando una mejor manera de salvaguardar sus datos, diré que es fundamental elaborar una lista personal de necesidades, ya que las soluciones van a depender de ellas. Éstas son las mías:

  • Tiene que ser automático. Ya tengo bastantes preocupaciones en mi cabeza como para sumar una mas. Si tengo que acordarme de conectar un disco duro externo cada cierto tiempo para volcar mis datos, no lo haré nunca.
  • Tiene que estar redundado. No quiero tener una sola copia, quiero al menos dos en diferentes lugares. Las probabilidades de que, llegado el momento de necesidad, acceda a la primera copia y haya algún problema son altas. Suelo estar gafado en esto.
  • Me tiene que proteger de desastres físicos como sobretensión, robo, incendio, o inundación. Por lo tanto, es fundamental tener una copia fuera de casa, en lugar remoto.
  • Me tiene que proteger de malware/ransomware, así como de corrupciones esporádicas de datos debido a bugs en las aplicaciones que manejan los archivos.
  • Me tiene que proteger de mis propias torpezas. Puedo llegar a borrar o alterar un archivo de forma accidental y sin darme cuenta. Es más, no tengo por qué descubrir el problema al momento, pueden pasar semanas o meses hasta que vea que ha pasado algo, cuando quiera volver a abrir un archivo y vea que no existe o está corrupto.

Solución Antigua: Centralizada, basada en Historial de Archivos de Windows + CloudBerry Backup

En mi ecosistema, las máquinas que contienen datos susceptibles de necesitar copia de seguridad son todas Windows 10. En el pasado tuve muy buenas experiencias con Time Machine de OS X, así que en su momento diseñé la solución confiando en que el intento de clon de Microsoft, su Historial de Archivos, sería igual de bueno. La solución que describiré ahora es la que he estado usando durante unos 3 ó 4 años, y que sólo hace unas pocas semanas descubrí cuán equivocado estaba con ella.

La solución

Se trataba de una solución centralizada en el NAS, y con una segunda copia de seguridad en un servicio de almacenamiento remoto.

¿Por qué centralizada en el NAS? Por aquel entonces mi conexión a Internet era asimétrica con unos 5 Mbps de subida, por lo que no quería tener que dejar los clientes encendidos a la espera de que completaran la copia de seguridad al almacenamiento remoto. Volcar una tarjeta de 20 GB con fotos podía suponer una carga de 9 horas al almacenamiento remoto, por lo que mi estrategia era que los clientes hicieran una copia local al NAS, mucho más rápida, y sería el NAS quien se encargue de forma centralizada de agrupar las copias de todas las máquinas y subirlas al almacenamiento remoto.

Diagrama de solución antigua: copias centralizadas en el NAS, basado en Windows File History + CloudBerry Backup

Cada cliente hacía una copia con Historial de Archivos a un recurso compartido en el NAS por Samba, y más tarde el NAS sincronizaría la copia de forma centralizada con BackBlaze B2 usando CloudBerry Backup para Linux. Todo sonaba bien.

Internet, donde el NAS almacena la segunda copia de seguridad

Los problemas

Sin embargo, recientemente he descubierto que Historial de Archivos no es fiable y tiene múltiples carencias. Para mi caso de uso, éstas son las más importantes:

  • Fallos silenciosos: no avisa de ninguna manera de que la copia ha ido mal, y desde la propia herramienta se indica la copia como completa aunque hayan ocurrido errores. Hay que mirar a mano en el Visor de Sucesos, mensaje por mensaje.
  • No copia archivos que incluyan ciertos caracteres, que sí son admitidos por el filesystem de Windows.
  • No copia archivos con rutas que superen los 255 caracteres en destino, y como añade timestamp a los nombres de archivo, aumenta el riesgo. El timestamp añade la nada despreciable cifra de 26 caracteres al nombre de archivo.
  • No hay forma de que reintente los archivos fallidos: re-run, disable/enable, reconfigure no funcionan. Una vez que un archivo falla, no lo vuelve a intentar nunca más.
  • La única manera de reintentar es destruir toda la copia y hacerla de cero, tardando horas, dejando los datos desprotegidos todo ese tiempo, y causando duplicados en el almacenamiento remoto debido al timestamp en los nombres de archivo.
  • No hace un almacenamiento inteligente de versiones: las opciones se limitan a retener todas las copias en los últimos X meses, pero sin tener opción a disponer de mayor granularidad para los días más cercanos, o conservar una copia al mes para los últimos meses o años.

En mi caso concreto, descubrí que faltaban en torno a 12.000 archivos en mi copia de seguridad, estando afectadas todas las fotografías tomadas entre los años 2010 y 2014, entre otras cosas, y que nunca habían tenido realmente copia de seguridad. Si hubiera ocurrido un fallo en mi almacenamiento principal, hubiera perdido 5 años de fotografías.

Conclusiones

Al descubrir estos problemas, especialmente que había estado sufriendo durante años una sensación de falsa seguridad al pensar que tenía copia de ciertos archivos que realmente no tenían copia, concluí lo siguiente:

  • Debo verificar las copias de seguridad de una manera más exhaustiva. No sólo debo comprobar que la copia se pueda restaurar, también debo comparar el contenido de la copia contra el origen para verificar que los datos son correctos. Al menos debería comprobar nombres de archivo, tamaños, y cierta verificación inteligente en las fechas de modificación. Idealmente también podría calcular hashes del contenido y comparar dichos hashes para verificar que no existe corrupción de datos.
  • Debo diseñar una nueva solución técnica de copias de seguridad, adaptada a mis necesidades actuales y con herramientas más fiables.

Solución Nueva: Descentralizada, basada en Duplicati

Uno de los problemas de la solución anterior es que todo se basaba en una herramienta fallida: Historial de Archivos de Windows. Necesitaba otras herramientas. Una primera aproximación era pasar a utilizar CloudBerry Backup directamente en los clientes. Sin embargo, debido al coste de licencias ($50 por máquina) descarté esta opción, ya que no es lo mismo pagar una única licencia para el NAS y centralizarlo todo ahí, que pagar N licencias, una para cada cliente.

Otro de los problemas es que, al ser una solución centralizada, el NAS se convierte en punto único de fallo (single point of failure). Si el NAS cae, tanto la copia del NAS como la copia remota dejarían de funcionar. Toda la solución se basa en que una máquina concreta funcione correctamente todo el tiempo. Pensé que sería conveniente evitar eso.

La solución

Actualmente dispongo de una conexión de fibra simétrica con 600 Mbps de subida, por lo que la necesidad inicial de centralizar las copias en el NAS desaparece. Ahora mismo, volcar una tarjeta con 20 GB de fotos suponen unos 5 minutos de tiempo de carga al almacenamiento remoto, frente a las 9 horas que necesitaba hace unos pocos años. Es perfectamente asumible que ahora sean los propios clientes los encargados de sincronizarse con el almacenamiento remoto directamente, liberando al NAS de hacer esta tarea.

Esto además tiene otro importante beneficio, y es que cada cliente mantendrá dos copias de seguridad independientes. Si una de ellas se vuelve corrupta por la razón que sea, la otra no tiene por qué estarlo también. En el antiguo esquema, si la copia del NAS se volvía corrupta, lo que se subía al almacenamiento remoto también lo iba a estar, ya que era una «copia de la copia».

Sobre el software, tras investigar diversas herramientas que soportaran tanto copias por red como copias a servicios de almacenamiento remoto como Amazon S3 o BackBlaze B2, y que tuvieran un coste asumible, me decanté por Duplicati.

Duplicati es un proyecto GNU/GPL y multiplataforma, que proporciona una solución de copias de seguridad fiable, robusta, con soporte para múltiples destinos, incluyendo los servicios de terceros más populares. Encontré muy buenas referencias de él, hay mucha gente contribuyendo, y no vi grandes bugs en el historias de cambios del proyecto en GitHub. Por ello, decidí darle una oportunidad.

Diagrama de solución nueva: copias descentralizadas, basado en Duplicati

He instalado Duplicati en cada cliente, definiendo dos copias de seguridad:

  1. Una copia diaria al NAS por Samba, con almacenamiento inteligente de versiones. Cada cliente copia a un directorio diferente.
  2. Una copia diaria a BackBlaze B2, con almacenamiento inteligente de versiones. Cada cliente copia a un bucket diferente.

Conclusiones

Llevo unas semanas, y hasta la fecha mis impresiones son muy positivas. Las copias se completan con bastante velocidad, tengo dos destinos independientes, y por lo que he podido comprobar, esta vez sí que están todos mis archivos importantes incluidos en la copia. Además, cuando ocurre un problema, se visualiza una notificación en el cliente, aunque hubiera estado bien poder configurar un email donde recibir y centralizar tanto notificaciones de copia completada como de copia fallida. Quizá podría contribuir al proyecto creando esa funcionalidad.

Siguientes pasos

Lo más importante es asegurarme de que las copias de seguridad siguen siendo fiables con el paso del tiempo. Por ello, debo diseñar un sistema de comprobación del contenido de todas las copias, tanto del NAS como del almacenamiento remoto, y no solo debe comprobar que la copia sea restaurable, sino que estén todos los datos, y que estos sean correctos. Y por supuesto, tiene que hacerse de forma automática. Si no me puedo fiar de mí mismo para hacer una copia de seguridad manual de forma regular, tampoco puedo fiarme de que vaya a estar comprobando las copias cada mes. Quizá lo haga el primero, pero os aseguro que después me olvidaré.

El sistema de comprobación debe:

  • Restaurar los datos automáticamente desde cada origen: NAS y B2.
  • Comprobar que todos los archivos del origen se encuentran en la copia.
  • Comprobar que los tamaños y fechas de archivo entre el origen y la copia se corresponden.
  • Enviar una notificación por email cuando la verificación sea correcta.
  • Enviar una notificación por email cuando haya ocurrido un problema de verificación junto con un informe que contenga el detalle, enumerando cada archivo con problemas y el error detectado.
  • Ejecutarse de forma automática y periódica, inicialmente una vez al mes.

Conclusiones finales

Si hay algo peor en informática que la falta de seguridad, es la falsa seguridad. La falsa seguridad es cuando igualmente no estás seguro pero ni siquiera lo sabes, y por lo tanto asumes riesgos que de otra manera no hubieras asumido. En mi caso estaba tranquilo y confiaba en mi sistema de copias de seguridad, cuando en realidad hubiera perdido muchos datos únicos en caso de catástrofe.

Afortunadamente no lo he llegado a sufrir, lo he detectado a tiempo (de casualidad, dicho sea), y he podido ponerle remedio. Pero otros podrían no correr la misma suerte que yo.

Las necesidades cambian con el tiempo, y la fiabilidad de las soluciones también. Revisa tus estrategias de vez en cuando, comprueba que tus soluciones sigan siendo buenas y cubran tus necesidades, y cambia tus soluciones cuando no sea así. Lo que ayer valía, hoy puede que no lo haga. El cambio es la única constante.

Red Samba demasiado lenta en Mac OS X

¿Estás experimentando transferencias muy lentas por red Samba desde tu Mac?. A mí me ha ocurrido tratando de copiar archivos desde mi servidor con Ubuntu Server a mi Mac Mini con Snow Leopard.

Algunos se refieren a él como un bug existente en la implementación TCP de Mac OS X por su base BSD, bug que hace tiempo fue corregido en distribuciones como NetBSD.

El problema se debe al uso del llamado Algoritmo de Nagle, que retrasa el envío de paquetes pequeños introduciendo tiempos de espera de hasta 500ms. Esto es posible porque TCP no impone cuándo deben enviarse los paquetes por la red, ni cuándo deben entregarse a la capa superior los paquetes recibidos. De esta manera, al esperar a acumular datos para el envío, se ahorra ancho de banda. El problema es que esta medida introduce muchísimo retardo en determinadas circunstancias, especialmente en entornos LAN, ya que está más enfocado a redes WAN donde el retardo intrínseco es alto.

Pero vamos al turrón. Para comprobar si nuestro problema se basa al retardo que introduce el Algoritmo de Nagle, lo mejor que podemos hacer es cambiar la configuración desde la consola de nuestro Mac de esta manera:

$ sudo sysctl -w net.inet.tcp.delayed_ack=0

A continuación podremos hacer una prueba de red para ver si el rendimiento mejora. En mi caso, a la hora de recibir archivos por Samba, he pasado de unos tristes 100KB/s a unos más que generosos 11MB/s.

Si queremos hacer el cambio permanente deberemos editar el archivo /etc/sysctl.conf (que por defecto no existe) y añadir al final la línea net.inet.tcp.delayed_ack=0

Tunelizando un proxy a través de SSH

Imagínate que estás con tu portátil en el aeropuerto, en un bar, en la calle, o en cualquier otro lugar remoto. Imagínate que estás conectado a Internet a través de una WiFi sin encriptación o de la que no te fías un pelo, y quieres consultar tu correo o entrar en una web que no utiliza cifrado. ¿Qué haces?

Conectarte a una WiFi libre y/o pública tiene su encanto, pero también tiene sus riesgos. Cualquiera de los otros usuarios de la red puede monitorizar todas tus comunicaciones, y partiendo de la base que hay mucho cabrón suelto, mejor curarse en salud. Si la página web que queremos visitar no utiliza cifrado (HTTPS) se lo vamos a poner nosotros. Al menos durante parte del camino. Vamos a montar un proxy remoto y lo vamos a «tunelizar» a través de SSH.

Lo primero es presuponer de nuevo que disponemos de una máquina Linux accesible desde el exterior por SSH, por ejemplo instalada en casa y con permisos de paso a través del router para el puerto 22/TCP. Un router del tipo Linksys WRT54GL de nuevo nos vale para estos menesteres. Solo tendremos que flashearlo con algún custom firmware, como DD-WRT. Así no necesitaremos tener un ordenador en casa siempre encendido.

Vamos con el portátil. Estamos conectados a través de una WiFi pública y queremos meter nuestro nombre de usuario y clave en una web sin cifrado. Lo primero sería conectarnos por SSH a nuestra máquina remota:

Vamos a ver cómo se haría con Putty para Windows.

1. Lo primero es irnos a la sección «Connection / SSH / Tunnels» y configurar allí el tunel SSH. Debemos marcar la opción «Dynamic», escribir un puerto local libre en «Source port» y pulsar «Add». En mi caso he elegido el puerto «8000». La configuración debería quedarnos como en la segunda captura (pincha para ampliar):

2. Ahora, en «Session» introducimos la IP o el nombre del servidor SSH en «Host Name», marcando «Connection type» como «SSH». Como probablemente usemos bastante esta configuración, nos interesará guardarla añadiendo un nombre en «Saved Sessions» y pulsando a continuación «Save» (pincha para ampliar):

3. La configuración de Putty ya está. Solo nos queda configurar el navegador para que utilice nuestro tunel SSH. Para ello deberemos ir a la configuración del proxy de nuestro navegador preferido, marcar «Socks 5», y como proxy «localhost» con el puerto que hayamos configurado en Putty. En nuestro ejemplo sería el 8000. Aquí tenéis algunos ejemplos de configuración, tanto para Internet Explorer como para Firefox (pincha para ampliar):

Ahora, cada vez que queramos hacer un canal seguro entre la red desde la que nos conectamos y una red «confiable», solo tendremos que iniciar sesión SSH con Putty usando el perfil que hemos creado en los pasos anteriores, y establecer la configuración del proxy en el navegador.

Los usuarios habituales de Firefox deberían probar las extensiones QuickProxy (cambio rápido de proxy con un click) y FoxyProxy (soporta múltiples perfiles, permite añadir reglas y filtros, mantiene listados de páginas que deben ir por una u otra configuración… muy potente).

¡Feliz navegación!

Encendido y apagado remoto de una máquina Windows desde Linux

Vamos con una entrada rápida. ¿Quién no tiene en su casa una máquina montada con Linux y encendida 24h al día, 365 días al año?. ¿Que no la tienes?. ¡Venga ya!

(Espérate a mi super artículo sobre cómo preparar un servidor casero basado en Linux, si es que algún día lo acabo…)

Muchos de nosotros tenemos un servidor de descargas en casa montado en una máquina Linux, o incluso un router basado en Linux (como el Linksys WRT54GL), que podemos utilizar como pasarela para encender y apagar nuestro PC habitual. Supongamos que disponemos de acceso por SSH desde el exterior a nuestra máquina Linux, y que queremos encender de forma remota nuestro PC habitual para recuperar algunos documentos de su disco duro.

Necesitaremos: samba y alguna utilidad WOL:

# sudo aptitude install wakeonlan samba-client

Con esto tenemos todo el software que necesitamos. Para hacer el encendido y apagado remotos además necesitaremos conocer la IP y MAC de la máquina remota que queremos manejar.

Para despertar la máquina usaremos Wake On Lan (debe estar activado en la BIOS de la máquina a despertar):

# wakeonlan 00:11:22:33:44:55

Y para apagar de forma remota usaremos Samba:

# net rpc shutdown -t 10 -f -C «Apagando el sistema de forma remota…» -I 192.168.0.2 -U usuario%password

El parámetro «-t» expresa el tiempo de espera antes de realizar el apagado, «-f» indica forzar la terminación de todos los programas (garantiza que no se quede a la espera de algún programa y no se apague), «-I» permite establecer la IP de la máquina remota, y por último «-U» establece un usuario con permisos para realizar el apagado. Si no queremos indicar el password en el prompt podemos eliminar la última parte «%password», y la utilidad net nos preguntará la clave al estilo sudo.

En otro capítulo veremos cómo se puede acceder a esa máquina por Terminal Server (en Windows XP: Escritorio Remoto) sin necesidad de abrir puertos en el router, y con una conexión 100% cifrada. La pista de nuevo es SSH, una herramienta con mucho poder. Pero primero veremos cómo tunelizar y activar un proxy dinámico para lo que pudieramos necesitar.

CaspaServer HOWTO (o como montar un servidor en casa)

El siguiente artículo lo escribí para un amigo hará ya unos dos años. En principio lo hice para ilustrar a un buen amigo mío, que quería montar un servidor casero similar al que yo tenía en lo alto de un armario. Así que para ayudarle a él escribí lo siguiente, que quizá ayude ahora a más gente. Dice así:

—————————–

Bienvenidos al curso de administración remota CaspaServer. En él aprenderán las diferentes técnicas para administrar remotamente su servidor CaspaServer v1.0 basado en Windows 2000 Server e instalar servicios. Más adelante explicaremos como hacer esto mismo con sistemas operativos a los que estamos más acostumbrados, como pueda ser un Windows 2000 Pro o un Windows XP Pro, pero en principio vamos con el Server ya que esto nos va a dar posibilidades para hacer otro tipo de cosas en un futuro.

Qué es un caspaserver
Un caspaserver es un pc casposo subido en algún armario encendido con el fin de funcionar a modo de servidor de Internet o de la propia intranet hogareña.

Para qué sirve
El caspaserver nos puede servir para tener nuestro propio servidor web en casa, aprovechando la adsl que pagamos religiosamente mes a mes. También podemos usarlo como servidor ftp, servidor de correo, servidor wins, servidor dhcp, router nat, o simplemente como pc de descargas.

Un buen caspaserver, por definición, no tendrá monitor ni teclado, por lo que podrá dejar tirado en algún recóndito lugar de nuestra casa, allá donde no moleste, y manejarlo remótamente desde nuestro pc habitual, por lo que la administración remota es uno de los platos fuertes de este artículo.

Instalando nuestro caspaserver
Lo primero que deberemos hacer será decidir el método para manejar el CaspaServer de forma remota. Las opciones en el mercado son muchas y variadas: escritorio remoto de Windows XP, Anywhere, VNC. Sin embargo, la que recomendamos en este curso es Terminal Server, incluído de serie en Windows 2000 Server.

Terminal Server es un servidor que nos permite manejar el CaspaServer desde otro ordenador como si estuvieramos trabajando directamente con él. El teclado y ratón se transmiten por red hasta el CaspaServer, que devuelve la imagen también por red al ordenador cliente que estemos manejando, para ser mostrada en su pantalla. Se trata de un telnet en modo gráfico.

Para disponer de Terminal Server deberemos instalar Windows 2000 Server en el CaspaServer. La instalación no difiere apenas respecto a Windows 2000 Pro, pero no debemos olvidarnos de seleccionar el componente «Servicios de Terminal Server» y configurarlo en modo «Administración Remota» cuando se nos pregunte, un poco más adelante en la propia instalación de Windows 2000 Server.

También podemos aprovechar ya instalar otros servicios que puedan resultar de interés, relacionados con IIS (Internet Information Server) como por ejemplo servidor web o servidor ftp, aunque para este último, el curso de administración remota CaspaServer v1.0 recomienda utilizar en su lugar un programa llamado BulletProof FTP Server de pago, o bien la herramienta gratuíta FileZilla Server, clon del anterior. El servidor web de IIS también puede ser sustituido por el conocido servidor web de libre distribución llamado Apache, que será tratado más adelante.

Una vez que la instalación de Windows 2000 Server haya concluído, tendrá que crear los disquetes del programa Cliente de Terminal Server, necesario para manejar remotamente el CaspaServer. Para ello dirígase al Panel de Control/Herramientas administrativas/Creador de cliente de Servicios de Terminal Server, y prepare dos disquetes en blanco. Una vez creados los disquetes utilícelos para instalar el Cliente de Terminal Server en aquellos ordenadores desde lo que desea manejar el CaspaServer.

Aprovechando que aun se encuentra trabajando físicamente con el CaspaServer, compruebe la correcta configuración de la red e instale aquellos programas que considere necesarios. Nótese que cualquier operación que quiera realizar físicamente la podrá hacer también remotamente gracias a Terminal Server, sólo que la respuesta de Terminal Server es ligeramente más retardada que cuando trabaja directamente con una pantalla y teclado conectados al CaspaServer. Aproveche ahora para instalar programas como BulletProof FTP Server si desea disponer de un servidor FTP, eMule o BitTorrent si desea descargar archivos de redes p2p, o Flashget para esas grandes descargas via web que desearía poder hacerlas desde el CaspaServer. También puede instalar complementos para su servidor de páginas web, como por ejemplo motores de bases de datos SQLServer o MySQL, o preprocesadores de scripts de PHP, ASP.NET o JSP/JavaBeans/Servets. Sin embargo, esto merece mención aparte y será tratado en una futura segunda entrega del curso de administración remota CaspaServer.

Las últimas operaciones que deberemos hacer antes de desconectar definitivamente teclado, ratón y pantalla del CaspaServer serán comprobar que efectivamente la red está correctamente configurada y por lo tanto podemos entrar en él mediante Terminal Server desde otro ordenador, y desactivar en la BIOS la parada por errores, para evitar que el CaspaServer espere indefinidamente la pulsación de la tecla F1 al no detectar teclado o pantalla. Esta opción se encuentra dentro de la sección ‘Standard CMOS Setup’, y se llama ‘Error Halt’, en la que deberemos seleccionar ‘No Errors’. Una vez realizados estos últimos puntos ya tendremos el CaspaServer listo para funcionar de forma autónoma. Retiramos teclado, ratón y pantalla, y dejamos a nuestro CaspaServer sólo con alimentación y cable de red (o tarjeta Wireless) colocado en cualquier rincón de nuestra casa, como por ejemplo tumbado encima de un armario.

A partir de ese momento el manejo del CaspaServer se realiza de forma análoga a un ordenador normal, solo que mediante el Cliente de Terminal Server, y suponiendo que nuestros lectores ya conocían el manejo de las utilidades típicas aquí presentadas (Flashget, eMule…), el uso del CaspaServer llegado a este punto no acarrea misterio alguno.

Feliz Administración!!

Configurando nuestro router
Dada la proliferación de conexiones ADSL con router que existen en España, el administrador del caspaserver probablemente se encuentre con que los servicios que con ilusión y esfuerzo ha configurado no son accesibles desde el exterior. Esto se debe a que nuestro router cierra todo el tráfico entrante, rechazando toda petición desconocida.

Para poder hacer visible desde el exterior nuestro servidor web ó ftp deberemos irnos a la configuración de nuestro router y abrir el puerto correspondiente (80 para web, 21 para ftp, 23 para telnet…). Asimismo tendremos que indicar la ip privada de nuestro caspaserver hacia el que tendrá que redirigir la petición.

Cada router es un mundo, y dependiendo de la marca y modelo del que poseamos los nombres varían, la forma de acceder o configurar también, por lo que desde este tutorial le remitimos al manual de su router o a foros especializados para aprender a abrir puertos. Se trata de un paso fundamental, así que procure familiarizarse con estos prodecimientos antes de continuar.

Usando nuestro servidor web IIS
El servidor web incluido en Windows 2000 Server, llamado Internet Information Server, ya habrá sido instalado en los pasos previos si ha seguido correctamente este curso de iniciación. El servidor inicia automáticamente junto con el ordenador, y no requiere configuración o intervención por parte del administrador para su uso normal.

Si es un lector sagaz habrá comprobado como un nuevo y extraño directorio ha crecido en su disco duro. La ubicación es c:inetpub, y dentro de este directorio se encontrará otro con un nombre tan peculiar como ‘wwwroot’. Esa es la raiz de nuestro servidor web, y para publicar una web, colgar un archivo o guardar una foto para mostrar en este u otros foros no tendrá más que copiarla dentro de ese directorio.

Recomendamos sin embargo hacer una clasificación inteligente de los archivos que en él se van almacenando, ya que con el paso del tiempo el caos se adueñará de su caspaserver y ya no sabrá que vale y que no. Cree un directorio ‘imagenes’ para sus imagenes, un directorio ‘files’ para los archivos que quiera poner a disposición del público, y un directorio por cada página web que quiera colgar. Esto hará mucho más fácil la administración y revisión de los contenidos del servidor web.

Extendiendo las posibilidades del servidor web: PHP y MySQL
— Proximamente —