Seguridad de TI: el Antivirus (Parte II)

Después de haber seleccionado el antivirus de la corporación (se adquirieron lotes de licencias distintos para cada empresa), se procedió a su instalación apoyados por el proveedor (Ingedigit).

Para la instalación decidimos utilizar el mismo servidor que se usaba para WSUS (un HP DL380 con 2Gbytes de memoria RAM y dos discos de 146GBytes sin redundancia) ya que nos pareció que este servidor estaba subutilizado y además así se centralizarían las funciones de “difusión de software”.

En cuanto a la topología se optó por tener un servidor de administración (el ya mencionado) y, en las dos grandes sedes remotas, habilitar las funciones de redistribución de la huella a los servidores de archivos allí presentes.

Se definieron distintas políticas de búsqueda de la huella en las PCs que dependía de su ubicación geográfica, de esta manera las PCs y los servidores en las sedes remotas buscaban sus huellas localmente para así no ocupar el enlace sin necesidad (el ancho de banda tomado por varias PCs buscando sus huellas donde no debían, no es despreciable para nada).

También se implementaron distintas políticas para el scanning periódico de los discos duros locales de las PCs: las PCs que atendían las taquillas del banco eran MUY utilizadas durante los medios días mientras que las demás no. En cuanto a los servidores se tomó en cuenta cuando hacían trabajo nocturno para que no coincidiera con el scanning.

En cuanto a los resultados…

Tuvimos un momento en el cual parecía que las oleadas de virus eran indetenibles y que en cualquier momento el negocio propiamente se iba a ver afectado, sin embargo se tomaron varias medidas simultáneamente que lograron bajar las aguas a su nivel:

1)     Remoción del privilegio de navegación a Internet a los usuarios que no lo necesitaban y restricción al acceso a sitios web a otros usuarios

2)     Incorporación de algunas políticas de seguridad de Windows distribuidas desde el Directorio Activo. En particular se desactivó el “Autorun” en los PenDrives y el “scheduling” ya que son mecanismos muy usados por los virus para reproducirse. Como al año de haber implementado estas medidas, Microsoft nos dio la razón ya que envió un “patch” de seguridad en el cual se desactiva el autorun

3)     Cambio de la herramienta antivirus de eTrust a Kaspersky

4)     Incorporación paulatina de la distribución de patchs de Windows mediante WSUS

Luego que se tomaran estas medidas, rápidamente la cantidad de PCs con virus decayó notablemente y al rato se hizo excepcional y totalmente manejable por HelpDesk. Hay que decir que los servidores estuvieron prácticamente a salvo siempre de los virus, seguramente debido a una política mucho más agresiva en cuanto a la actualización de las mejoras de seguridad de Windows y a que nunca fueron usados para navegar por Internet o se le instalaran programas P2P que hacen un daño tremendo.

Seguridad de TI: el Antivirus (Parte I)

Ya en otra oportunidad comenté sobre aspectos genéricos de Seguridad de TI, en esta me voy a concentrar sobre lo relacionado con el antivirus que se instala en PC y servidores.

En primer lugar hay que responder una pregunta muy importante: hace falta el antivirus en una red de computadoras corporativas? La respuesta es SI.

¿Cuáles son los aspectos a tomar en cuenta a la hora de adquirir una solución de este tipo?

1)     Efectividad. Nosotros tratamos de preparar un laboratorio nuestro para hacer una evaluación del comportamiento de los distintos antivirus para ver cual era el más efectivo… eso es una locura! Lo mejor para ver este aspecto es consultar a varias revistas o sitios web especializados y fiarse de sus criterios.

2)     Pesadez. Tipicamente los antivirus son muy intrusivos y algunos toman tantos recursos de la máquina que enlentecen el trabajo en un forma importante; este aspecto es clave y es fácilmente evaluable por la organización: se instala el antivirus en un ambiente de pruebas y se nota el comportamiento con las aplicaciones del negocio, al momento de actualizar la huella y al momento de hacer el scanning del disco duro local. Además hay que tomar en cuenta la configuración “típica” de los PC de la organización, no la mejor!

3)     Multiplataforma. El antivirus debe servir por lo menos para los distintos sabores de Windows para PC y para servidores (incluyendo las versiones de 64 bits). Idealmente debe servir también para los Linux más populares (Red Hat y Suse), para servidores de correo (Exchange, Dominó, Postfix) y para Proxy, claro que depende de la plataforma de cada organización.

4)     Administración centralizada. En un ambiente corporativo la facilidad de administración centralizada es esencial, se deben contemplar al menos los siguientes aspectos:

a.       Consola que refleje el status de todos los PC con el antivirus instalado (que huella tiene, resultado del último scan, versión instalada, etc.) incluyendo la visualización del log de actividad.

b.       Distribución de políticas distintas para grupos de PCs para sí poder discriminar entre los que necesitan ciertos aspectos habilitados y los que no.

c.       Forzado de acciones. Frente a una epidemia, se debe tener la facilidad de poder obligar a todos los PC para que actualicen su huella de inmediato o que comiencen un scan del disco duro.

d.       Control remoto de los parámetros, sin posibilidad de que el usuario pueda cambiarlos localmente.

5)     Hay otros aspectos de la administración centralizada que son deseables mas no esenciales tales como la instalación remota del antivirus o el manejo del licenciamiento.

6)     Marca. Evidentemente la marca del antivirus debe ser reconocida.

7)     Soporte local. Es mucho mejor si hay un soporte en el país al cual se pueda recurrir a la hora que las cosas se salgan de control o para el aprendizaje inicial.

En mi trabajo tuve la oportunidad de instalar dos soluciones de antivirus:

eTrust. Aún cuando hace algunos años era nombrada como una buena solución (además de pertenecer a una gran casa de software como lo es Computer Associates), rápidamente se quedó atrás y dejó de detectar los virus. Era muy buena del punto de vista de administración centralizada, pero no se hace nada si deja entrar a los virus. Hasta donde yo sé, ya no se comercializa.

Kaspersky. Este software se adoptó en el 2009, en su momento la necesidad que se tenía era la de proteger a las estaciones de trabajo, los servidores y el proxy (se trataba del ISA Server de Microsoft). Se adquirió entonces la suite “Business”, que incluía la protección para móviles, servidores y PCs; la solución que incluía un cliente para el proxy, la “Total”, era mucho más costosa debido a que también tenía el cliente para el sistema de correos (Exchange o Dominó) pero que a nosotros no nos servía ya que usábamos Postfix de Unix (ahora SI soportan esta mensajería en servidores Linux RedHat). Kaspersky resultó ser bastante bueno, se configuraron servidores remotos para la distribución de la huella en otras localidades (y así ahorrar ancho de banda en los enlaces privados) lo cual funcionó perfectamente. Me gustó también el manejo del licenciamiento (da un 20% de margen en la cantidad de licencias) y la interfaz administrativa. No es infalible (como no lo es ninguno) pero tiene un buen tiempo de respuesta frente a las amenazas. El Scanning del disco duro pone la PC bastante lenta, nosotros lo pusimos los viernes al medio día para disminuir la molestia pero siempre se notaba su funcionamiento.

Se contemplaron otras opciones como las de Symantec, McAfee y Panda, pero Kaspersky fue la que nos gustó más y también fue la mejor presentada por el proveedor.

En la próxima entrega la implementación y los resultados.

Cluster de Servidores Unix: la implementación

Una vez determinado que íbamos a implementar un cluster del tipo Activo – Pasivo con dos servidores Unix HP idénticos (ver blog) nos informamos sobre la solución de HP al respecto… se llama Service Guard, su filosofía me gustó mucho y funciona de la siguiente manera:

Service Guard de HP:

La idea de Service Guard es la de tener una red de servidores en la cual se definan los servicios necesarios (por ejemplo DNS, DHCP, Oracle, Apache, etc.) y en que servidores se desean que estén activos o pasivos.

Ejemplo:

Se desean tener los servicios de DNS, DHCP, Apache, Application Server, Oracle y MySQL bajo un esquema de Cluster Activo – Pasivo. Los servicios podrían estar distribuidos de la siguiente manera:

Servidor 1: DNS y DHCP

Servidor 2: Apache y Application Server

Servidor 3: Oracle

Servidor 4: MySQL

Pero también hay que definir que servidor tomaría las funciones de un servidor que se haya caído, así por ejemplo se podría tener:

Servidor 1:

Servicios Activos: DNS y DHCP

Servicios Pasivos: Oracle

Servidor 2:

Servicios Activos: Apache y Application Server

Servicios Pasivos: MySQL

Servidor 3:

Servicios Activos: Oracle

Servicios Pasivos: DNS y Apache

Servidor 4:

Servicios Activos:  MySQL

Servicios Pasivos: DHCP y Application Server

Así que si se cae el servidor número 2, los servicios de Apache levantarían en el servidor 3 y los de Application Server en el 4.

Con esta filosofía, siempre habría un servidor dispuesto a levantar servicios que se hayan caído del servidor que habitualmente los tiene. Esto Service Guard lo implementa mediante “paquetes” en los cuales se configura el servicio que tiene que vigilar, donde tiene que levantar en caso de caída, el script para arrancar un servicio dado, la IP relacionada, etc.

Claro está que, en caso de una caída, los servicios pueden tardar minutos en levantar en el servidor pasivo (dependerá de lo complicado de levantar esos servicios), por lo tanto este esquema es aceptable para el caso de negocios que pueden estar sin funcionar por un espacio de tiempo que se mida en minutos y no en segundos. Si la criticidad del negocio lo ameritara, claramente se tendrá que implementar un esquema Activo – Activo.

El caso nuestro fue bastante simple ya que los servicios a mantener eran tres únicamente: Oracle 10g, Oracle Application Server 10g y MySQL.

Se adquirieron dos servidores iguales:

·         HP rx3600 con un CPU Itanium cada uno (y posibilidad de un segundo)

·         8GBytes de memoria RAM (que tuvimos que ampliar al poco tiempo a 16)

·         4 discos SAS de 146GBytes cada uno

·         2 tarjetas de Fibra cada uno para acceder la SAN (un EVA4100)

·         4 tarjetas de red 10/100/1000 cada uno

·         HP UX 11i

La configuración de Service Guard fue:

Servidor 1:

Servicios Activos: Oracle AS 10g, MySQL

Servicios Pasivos: Oracle 10g

Servidor 2:

Servicios Activos: Oracle 10g

Servicios Pasivos: Oracle AS 10g, MySQL

La parte curiosa del asunto fue la relativa al acceso a la SAN, factor esencial ya que era necesario, obviamente, compartir los mismos datos entre los dos servidores: yo pensaba que la partición de la SAN a compartir simple­mente se vería por ambos servidores al mismo tiempo… algo parecido a cuando se comparte una carpeta en servidores Windows: en el momento que alguien crea un archivo en ella, inmediatamente el cambio es visto por los demás que la acceden. Eso es válido en una carpeta compartida en la red, pero no en una partición de la SAN que, para todos los efectos, es un disco local!

Total que aprendí que se definen las particiones en la SAN que serán usadas por cada servidor EN MOMENTO DISTINTOS es decir, cuando el servidor que la necesita está con el servicio en modalidad de “Activo”. El paquete de Service Guard es el que se encarga de activarla en el momento adecuado… de esta manera nunca hay dos servidores viendo la misma partición al mismo tiempo… hermoso!

Otra cosa interesante de los paquetes de Service Guard, es que tienen asociada una IP, con eso se logra que los clientes no tengan que ser reconfigurados: ellos siempre referencian a la misma IP (o idealmente a un nombre resuelto en un servidor DNS) y ésta es la que viaja de un servidor a otro de acuerdo a donde el servicio esté activo!

Claro que al tener una configuración como ésta, ya no se puede ser tan feliz a la hora de bajar un servicio ya que, a menos que se le indique lo contario a Service Guard, éste interpretará que se cayó el servicio y lo tratará de levantar en el otro servidor! Claro está que Service Guard viene con una batería de comandos para comunicarse y configurar los paquetes y evitar estos efectos dañinos.

Lo importante del caso es que se logró el objetivo propuesto: se pusieron en Alta Disponibilidad tres de los servicios más importantes de la organización, así las operaciones de manutención de los servidores fueron mucho más simples de llevar a cabo puesto que los servicios se detenían por tiempos muy cortos.

Cluster de Servidores Unix: el proyecto

Hace algunos años el tema de poner servidores en Cluster era todo un misterio que tenía un halo mítico que los hacía posibles solo en grandes organizaciones con grandes recursos técnicos de hardware, software y humanos. Hoy en día esta tecnología se ha vuelto al alcance de organizaciones medianas y hasta pequeñas; afortunadamente tuve una experiencia muy interesante implantando un Cluster en el Banco.

Antecedentes:

Aun cuando para todo personal técnico que necesita efectuar labores de manutención en la plataforma tecnológica el Cluster es algo muy práctico ya que permite retirar de operación un servidor SIN que la operación deje de funcionar, y, aun cuando para cualquier organización tener la garantía de que la operación siga funcionando a pesar de alguna falla de hardware o de software es lo ideal, lo que finalmente empujó la implementación del Cluster fue la reglamentación tecnológica de la Superintendencia de Bancos que inclusive le pide a los Bancos que posean un centro alterno para la continuidad de la operación en caso de desastres.

Aprovechando el proceso de reconversión monetaria (que necesitaba ambientes adicionales) y aprovechando la necesidad de una renovación y ampliación tecnológica, se planteó entonces la opción de implementar un Cluster de Servidores para lo relacionado con Oracle… es decir la parte crítica del negocio.

Las necesidades:

La necesidad básica era la de tener al motor de Bases de Datos y al servidor de aplicaciones en un ambiente de alta disponibilidad ya que el banco trabaja 7x24 y efectuar labores de mantenimiento en los servidores era siempre complicado.

Las opciones:

En lo relacionado al Hardware las opciones eran solo dos (por requerimientos del proveedor del software): Sun o HP. Hasta los momentos habíamos trabajado con un servidor Sun V440 que había hecho un buen trabajo, a pesar de haber pasado por una falla misteriosa relacionada con la tarjeta de red incrustada en la tarjeta madre que lo reinicializaba de cuando en cuando al azar; los que si habían fallado muchas veces, fueron los servidores de poca envergadura Sun de la familia V65x (con procesadores Intel) y en menor escala un V240… estas fallas nos habían dejado un mal sabor ya que los servidores HP DL380 no habían fallado nunca.

La gran duda, más allá del Hardware, era la de implantar un Cluster del tipo Activo – Activo o del tipo Activo – Pasivo… Oracle posee una solución espectacular, que se llama RAC (Real Application Clusters), que implementa Clusters del tipo Activo – Activo, es decir que todos los miembros del Cluster procesan transacciones en paralelo.

Aun cuando suene paradójico, quién inclinó la balanza a favor del esquema Activo – Pasivo fue el mismo Oracle o, mejor dicho, el esquema de licenciamiento de Oracle: al seleccionar un esquema Activo – Activo, Oracle requiere que se licencie su producto para cada servidor, si además se usa RAC, éste también deberá adquirirse en forma análoga. Yo entiendo que un esquema Activo – Activo se requiera para organizaciones que tienen millares de transacciones por minuto (una telefónica, un gran banco, etc.) pero esa no era nuestra realidad, por lo tanto el costo del licenciamiento de Oracle no era justificado de NINGUNA manera por nuestro negocio.

También se exploró la alternativa de tener no solamente una pareja de servidores gemelos para el Cluster, sino la utilización de servidores virtuales en ellos, de esta manera la portatibilidad y la flexibilidad de la solución eran únicos.  La idea era tener a dos servidores físicos con Unix conectados a una SAN, cada uno de ellos con dos servidores virtuales Unix (uno para Oracle y otro para el Application Server), de esta manera se tendría, además de la alta disponibilidad implementada entre los servidores reales, la alta disponibilidad inherente a la portatibilidad de los servidores virtuales de un servidor anfitrión a otro… una solución realmente espectacular!

Una vez más los sueños se disiparon cuando comenzaron los precios… sobre todo los del software. Parece increíble que a estas alturas, todavía las grandes casas de software no contemplen casos especiales para la virtualización: Oracle licencia sus productos de acuerdo al Hardware sobre el cual están instalados SIN importar si se trata de un servidor virtual que solo utiliza una fracción, HP hace lo mismo con sus productos (incluyendo HP UX) así que la instalación de la solución sobre servidores virtuales se hizo económicamente no viable.

Así que al final se optó por la implementación de un esquema de Cluster del tipo Activo – Pasivo sobre dos servidores HP conectados a una SAN.

El siguiente diagrama ilustra lo que se deseaba implementar (bien sea con servidores virtuales o reales). Los colores tenues indican los servicios en Pasivo:

La próxima semana contaré como fue la implementación propiamente.

Aplicación de DFS (Distributed File System)

Toda plataforma de tecnología pasa por transformaciones y evoluciones, es imposible que una plataforma tecnológica pueda servir a una organización moderna sin alteraciones a lo largo del tiempo: hay mejoras en servidores, en almacenamiento, en enlaces de comunicación, en software, etc. Típicamente el problema que se genera cuando se cambia información de un lugar a otro (por ejemplo cuando se pasan carpetas compartidas de un servidor a otro) es el impacto que tendrán los usuarios ya que se les altera el lugar al cual referenciaban… antes estaban en \\servidor-1\CarpetaPublica y ahora están en \\servidor-2\CarpetaPublica por lo tanto el departamento de HelpDesk tendrá que modificar los accesos directos y/o instruir a los usuarios sobre la novedad con la correspondiente molestia ya que, seguramente, habrá usuarios que no se enterarán.

Una excelente forma de evitar estas molestias es usando los DFS (Distributed File System) de Windows Server.

La filosofía de los DFS es muy simple: instruir al Directorio Activo de Windows para que distribuya los nombres de los recursos compartidos SIN que los usuarios siquiera se enteren a que servidor pertenecen. De esta manera los usuarios ya no se conectarán a \\servidor-1\CarpetaPublica sino a \\Dominio\Links\CarpetaPublica.

Los DFS son relativamente simples de implementar: se designa un servidor (generalmente un Controlador de Dominios) que será quién posea la tabla de equivalencia entre los nombres a difundir y su lugar físico correspondiente tal como se hizo referencia anteriormente.

A partir de ese momento los usuarios podrán referenciar a las carpetas compartidas mediante la nomenclatura que NO referencia al servidor. Ahora el departamento de TI tiene la facilidad de poder mover la información de un servidor a otro sin que los usuarios se enteren:

-          Se desactiva temporalmente la carpeta compartida a mover

-          Se mueven los archivos del servidor inicial al final

-          Se ajusta el DFS para que referencie a la nueva localidad

Listo!

Seguridad de TI: Experiencia con WSUS

Tal como comenté en una entrada de un blog anterior, la instalación del WSUS no fue demasiado complicada y se pudo efectuar sin demasiadas complicaciones. Tampoco fue muy complicado relacionar algunas políticas del Directorio Activo para instruir a los servidores con respecto al reboot automático cuando las mejoras de Windows así lo pidieran; los servidores Windows fueron así programados y se puede decir que no ocurrieron incidencias de importancia. Los inconvenientes surgieron con las PC… HelpDesk no tenía ninguna política de actualización con respecto a las PC, estos implica que las PC de los usuarios con más tiempo con ellas y muy conservadores a la hora de navegar en Internet y/o bajar programas, fácilmente tenía versiones de XP con SP1, por lo tanto de haberse incorporado al WSUS, éstas hubiesen recibido más de 1000 actualizaciones en las primeras de cambio! Para resolver este problema, que además se juntaba con el saneamiento de los Virus, se preparó para HelpDesk un área con todos los patch de seguridad de Microsoft organizados por Sistema Operativo e idioma (había algunas PC con Windows en inglés), ésta área era actualizada mensualmente con las nuevas actualizaciones. Adicionalmente se instruyó a HelpDesk para que, cuando les “cayese” en las manos una PC por alguna razón (típicamente porque tenía un virus), ésta se preparara con el último Service pack disponible para esa versión de Windows y luego se le aplicaran las actualizaciones de seguridad posteriores. Finalmente, luego que la PC en cuestión hubiese sido actualizada, nos informaban para que ésta se incluyera en el administrador del WSUS y así se mantendría actualizada en forma automática.

El esquema mencionado anteriormente funcionó bastante bien, el problema surgía cuando HelpDesk se olvidaba de notificarnos y así la PC dejaba de actualizarse automáticamente posteriormente.

En cuanto a las aplicaciones de las actualizaciones de seguridad de Windows, debo decir que nunca interfirieron con ningún programa… nunca nos pasó de que algún usuario se quejara que la aplicación X no funcionara adecuadamente a partir de una actualización. Personalmente si tuve algunos problemas con mi PC que tenía Windows 7: más de una vez me ocurrió que, a la mañana siguiente de que se le aplicar alguna actualización de Windows, la PC arrancaba de una forma extraña (con un escritorio en limpio, con Outlook desconfigurado, sin acceso a la carpeta de “Mis Documentos”, que teníamos localizada en un servidor de archivos, etc.) que me obligaba recurrir a la copia de seguridad que Windows efectuaba automáticamente para restaurar el Sistema Operativo a un estado previo a la actualización (que por cierto funciona perfectamente). Dado que no oí a ningún otro usuario quejarse de algo parecido, asumí que se trataba algo peculiar en mi PC y le resté importancia.

La parte más problemática de la distribución de las actualizaciones, es el reboot cuando éste hace falta. Con las PC no hubo mayores problemas porque, más temprano que tarde, son apagadas por los usuarios pero, para el caso de los servidores que no se apagan virtualmente nunca, se tuvieron que tomar ciertas políticas: en la mayoría de los casos los reboot se mandaban a efectuar automáticamente cuando sabíamos que no estaban realizando ninguna operación del negocio o, para el caso de los File Servers, en horarios en los cuales no debía haber nadie trabajando (nunca nadie se quejó de alguna pérdida de archivos debido a alguna reinicialización de algún servidor). Finalmente quedaban los casos de algunos servidores realmente críticos que, en teoría, no podían interrumpir sus labores nunca (por ejemplo los que atendían a los cajeros automáticos, el del Internet banking, el usado por el Call Center…), éstos los reiniciábamos manualmente en momentos que sabíamos que su ausencia no sería notada (generalmente cuando se tenían que bajar otros servicios de los cuales ellos dependían).

Por su lado la consola de WSUS nos informaba siempre el estado de cada servidor en cuanto a actualizaciones se refería con lo cual se podía hacer seguimiento de la distribución de alguna actualización en particular.

Respaldos: los FSB para Servidores Virtuales

Los servidores virtuales son un capítulo aparte en cuanto a los Full System Backup (FSB) dada su misma naturaleza.

En principio el FSB de un servidor virtual es la propia copia de los archivos que lo componen a otro dispositivo de almacenamiento, el problema es que la copia en vivo con el servidor operando puede que no sea confiable.

Para obviar el problema citado, lo mejor es seguir la regla de oro para los servidores virtuales: no usarlos para tener Bases de Datos de producción, veamos entonces cuales son las posibles opciones de uso de Servidores Virtuales:

Haciendo una matriz con las estrategias de respaldo para los posibles usos de los servidores virtuales se tiene:

Tipo de Servidor	¿Genera Datos? (1)	¿Es 7 x 24?	Estrategia de respaldos
Application/Web	NO	SI NO	Copia en caliente (2) Congelar y luego copiar (2)
File & Print	SI	SI NO	Copia en caliente (2) Congelar y luego copiar (2)
DNS/DHCP/etc	SI	SI	Copia en caliente (2)
Data Base	SI	SI NO	Acronis Congelar y luego copiar (2)

Acotaciones:

(1)  Se refiere a datos relevantes (la actualización de registros DNS o DHCP es importante aun cuando no se trate de datos del negocio)

(2)  El proceso de copiado es tremendamente impactante en los tiempos de respuesta del servidor  que se respalda e inclusive puede impactar significativamente a su anfitrión y, en consecuencia, a los demás servidores virtuales hospedados

Lo más recomendable como siempre es efectuar los respaldos en momentos que el servidor está siendo usado poco o nada, para ello se puede usar el Scheduling de Windows para activar la tarea de respaldo en un momento determinado en el servidor anfitrión.

Otra cosa importante a tomar en cuenta es: ¿Qué tanto hace falta respaldar un servidor que no genera datos del negocio? Para mi la respuesta a esta pregunta más bien depende de las actualizaciones del sistema operativo que se le realicen, de esta manera lo más oportuno es tomar una imagen del servidor ANTES de efectuar una actualización que pudiese afectar a las aplicaciones, es decir, para servidor Windows, una vez al mes salvo algunas excepciones.

Otra cosa muy importante a tomar en cuenta para este tipo de respaldos es el lugar en el cual se va a almacenar la copia: lo más oportuno es tener un servidor “barato” con mucho espacio en disco “barato” en el cual se tengan las imágenes de los servidores virtuales y no virtuales almacenadas; de esta manera, a la hora de una restauración ésta pueda efectuarse sin grandes espera de cintas. Este servidor, que sería distinto al de los respaldos normales, podría estar encargado de tener el software de administración de respaldos totales, como Acronis, así como ser el repositorio de las copias de los servidores virtuales que vendrían de las tareas agendadas en los respectivos servidores anfitriones.

Por último quería señalar que, bajo el supuesto de tener los servidores anfitriones con Microsoft Windows Virtual Server, sin importar si los servidores hospedados sean Windows o Linux, la solución de apagado, congelado y copiado de los servidores virtuales, puede implementarse sin necesidad de adquirir ningún software adicional.