Utilizamos cookies propias y de terceros. [Más información sobre las cookies].
Política de cookies
Proyecto AjpdSoft

· Inicio
· Buscar
· Contactar
· Cookies
· Descargas
· Foros
· Historia
· Nosotros
· Temas
· Top 10
· Trucos
· Tutoriales
· Wiki

Copias de seguridad: Sustitución servidor almacenamiento en producción siendo controlador de dominio
Windows


Os explicamos una situación habitual en una empresa: cómo sustituir el servidor actual de almacenamiento (datos) por uno nuevo de más capacidad. Os explicamos cómo hacerlo cuando utilizamos como sistema operativo Windows Server 2003. Además, en el ejemplo, el servidor de datos es un controlador secundario de dominio.



Consideraciones previas

Infraestructura de red y servidores inicial

Se dispone de la siguiente infraestructura de red y servidores:

AjpdSoft Sustitución de servidor de almacenamiento en producción siendo controlador de dominio W2003 - Esquema de red y servidores

A continuación explicamos cada elemento:

  • srvdominio: equipo con Windows Server 2003, que hace de controlador principal de dominio. Este equipo posee Active Directory y el catálogo global (base de datos de los usuarios, impresoras, equipos, etc. del dominio Windows). Este equipo fue promicionado en su momento mediante "dcpromo" a controlador principal de dominio.
  • srvbackup: servidor de copias de seguridad, con Windows Server 2003. Como software de copia de seguridad se utiliza Symantec Backup Exec. Este equipo está conectado a una unidad de cinta para las copias de seguridad.
  • srvdatos: servidor de almacenamiento actual en producción, con Windows Server 2003. Este servidor es un NAS y se usa para almacenar los datos de los usuarios, de las aplicaciones y bases de datos de escritorio. Este será el servidor que sustituyamos. Este servidor, para que los usuarios puedan acceder a las carpetas compartidas sin que les pida usuario y contraseña (estableciendo relación de confianza entre el equipo cliente y srvdatos) fue promocionado a controlador secundario de dominio, con lo cual comparte el catálogo global de Active Directory con srvdominio.
  • srvdatosn: servidor de almacenamiento como srvdatos, con más capacidad y mejores prestaciones, este será el servidor que sustituirá a srvdatos.
  • srvbd: servidor de base de datos Oracle con GNU Linux Red Hat como sistema operativo.
  • srvts1, srvts2: servidores de Terminal Server con Windows Server 2003 y los servicios de terminal server instalados. Estos equipos pertenecen al dominio establecido por srvdominio, pero NO son controladores de dominio.

Acciones que pretendemos realizar y explicar

Nuestro servidor srvdatos ha quedado obsoleto, la capacidad de los datos de los usuarios es de 500GB, y nuestro servidor srvdatos posee 550GB de almacenamiento y ya no es posible ampliarlo. Para solucionar este problema se ha optado por adquirir un nuevo servidor de almacenamiento (NAS) con más capacidad. Este caso hipotético es muy habitual en las empresas y organizaciones.

Así pues, lo que pretendemos es traspasar los datos de srvdatos a srvdatosn, también las carpetas compartidas y la configuración de seguridad. También hemos de dejar srvdatosn con el mismo nombre de red y misma ip que srvdatos (que apagaremos unas semanas) para que los accesos directos a datos de los usuarios configuraciones de aplicaciones que guarden datos en srvdatos se sigan manteniendo y el usuario no note la diferencia. Todo esto hemos de realizarlo en el menor tiempo tiempo posible, para que la disponibilidad del servicio no se vea mermada.

Resumen de pasos básicos a seguir y acciones a realizar:

  • Preparar srvdatosn (el que será el nuevo servidor de almacenamiento NAS), las siguientes tareas las podremos realizar en cualquier momento sin detener el servicio, por lo que no afectarán a la disponibilidad:

    • Si hemos de promocionarlo a controlador de dominio (dcpromo) probablemente tengamos que instalarle Windows Server 2003, puesto que los servidores NAS actuales llevan incorporado un sistema operativo específico para almacenamiento, que no permite promoción a controlador de dominio.
    • Es muy recomendable que la letra de unidad que utilicemos para almacenar los datos sea la misma que en el srvdatos en producción, de esta forma será más fácil transferir las configuraciones (carpetas compartidas y demás).
    • Puesto que en nuestro caso utilizaremos Symantec Backup Exec para realizar la transferencia de ficheros entre srvdatos y srvdatosn instalaremos el agente (cliente) de Symantec Backup Exec en este servidor.
    • Es conveniente promocionar este servidor (para realizar las pruebas oportunas antes de la transferencia), luego lo despromocionaremos (necesariamente para cambiarle el nombre de srvdatosn a srvdatos).
  • Si hemos utilizado el método de compartir carpetas en srvdatos para el acceso de los usuarios a las mismas, deberemos exportar la clave de registro: HKEY_LOCAL_MACHINESYSTEM/CurrentControlSet/Services/lanmanserver/Shares de srvdatos para al final importarla a srvdatosn, de esta forma volveremos a tener todas las carpetas compartidas sin necesidad de hacerlo manualmente.
  • A partir de este paso, es recomendable hacerlo en un momento no crítico puesto que desconectaremos los servidores de la red. Desconectaremos el servidor de copias srvbackup, servidor nuevo (srvdatosn) y servidor datos  producción (srvdatos) de la red local (siempre que sea posible) y dejarlos aislados, los tres conectados entre sí pero no a la red. De esta forma evitaremos que al hacer la copia de seguridad completa haya usuarios abriendo y modificando ficheros.
  • Puesto que utilizaremos Symantec Backup Exec para realizar la transferencia de ficheros y la configuración de seguridad (usuarios y grupos de seguridad que tendrán acceso a cada carpeta) entre srvdatos y srvdatosn, cuando hayamos aislado los tres servidores lanzaremos una copia completa de srvdatos a la unidad de cinta. Si no disponemos de un software y hardware de copia de seguridad podremos utilizar algunas herramientas para hacer la transferencia de ficheros de srvdatos a srvdatosn directamente, por ejemplo:
    • Robocopy (Robust File Copy): utilidad de Microsoft que permite copiar ficheros y configuraciones de seguridad de un servidor a otro. Permite copiar atributos NTFS, por lo que, en teoría, copiará los permisos de seguridad de las carpetas.
    • AjpdSoft Copia de Seguridad: software que permite copiar carpetas, aunque no copia permisos ni atributos NTFS, sólo carpetas y ficheros.
    • Otros programas de copia de seguridad (como Tivoli Storage Manager).
  • Tras la copia de seguridad completa, despromocionaremos el srvdatos en producción (con el comando "dcpromo"), para que no sea controlador de dominio, si no realizamos esta acción no podremos poner el nombre "srvdatos" al servidor "srvdatosn" puesto que "srvdatos" (aunque esté apagado) estará activo como miembro del dominio.
  • Apagaremos el equipo srvdatos tras copia y despromoción. Lo dejaremos intacto hasta que estemos seguros de que todo el proceso ha concluido satisfactiriamente, si hubiese algún problema, siempre podremos encenderlo, conectarlo a la red, promocionarlo a controlador de dominio y estará disponible para su funcionamiento normal.
  • Accederemos al controlador de dominio srvdominio, accederemos a "Usuarios y equipos de active directory", buscaremos en "Computers" el nombre "srvdatos", si aparece lo eliminaremos para no tener problemas a la hora de cambiar el nombre a srvdatosn.
  • Restauraremos la copia de seguridad completa que actuamente está en las cintas de la unidad de backup al srvdatosn.
  • Desconectar servidor de datos en producción (srvdatos) de la red aislada y encenderlo provisionalmente para comprobar el número de ficheros, número de carpetas y tamaño con respecto al servidor nuevo de datos (srvdatosn), tras la restauración, hemos de asegurarnos de que el proceso de transferencia de los ficheros ha sido correcto y completo.
  • Despromocionar el servidor nuevo srvdatosn (si estaba promocionado) para cambiar nombre y poner el mismo que el servidor en producción. Poner mismo nombre de red y misma IP que srvdatos. Reiniciar y comprobar que todo funciona correctamente.
  • Tras cambio de nombre, promocionar a controlador secundario de dominio. Volver a comprobar que los permisos son correctos y los recursos compartidos.
  • Conectar srvdatos (nuevo) y srvdominio a la red local.
  • Desde los equipos clientes comprobar que se accede correctamente a las carpetas compartidas y que se establece relación de confianza (no pide usuario y contraseña cuando el usuario ha iniciado sesión en un equipo con un usuario y contraseña que coincide con la del dominio Windows de srvdominio).
  • Cuando haya pasado un tiempo prudencial podremos encender el srvdatos "viejo" (sin que tenga conexión a la red) y cambiarle el nombre de red y la IP, volver a conectarlo a la red y así podremos formatear la unidad de datos para utilizarlo como servidor de datos secundario.

Explicamos algunos de los pasos más detalladamente

  • Preparar srvdatosn (el que será el nuevo servidor de almacenamiento NAS), las siguientes tareas las podremos realizar en cualquier momento sin detener el servicio, por lo que no afectarán a la disponibilidad:

    • Si hemos de promocionarlo a controlador de dominio (dcpromo) probablemente tengamos que instalarle Windows Server 2003, puesto que los servidores NAS actuales llevan incorporado un sistema operativo específico para almacenamiento, que no permite promoción a controlador de dominio. En el siguiente artículo explicamos cómo instalar Windows Server 2003:

Instalación de Windows Server 2003 Enterprise Edition SP2

    • Es muy recomendable que la letra de unidad que utilicemos para almacenar los datos sea la misma que en el srvdatos en producción, de esta forma será más fácil transferir las configuraciones (carpetas compartidas y demás). En el siguiente artículo explicamos cómo cambiar la letra de una unidad en Windows Server 2003:

    Cambiar la letra de una unidad de disco en Windows Server 2003

    • Puesto que en nuestro caso utilizaremo Symantec Backup Exec para realizar la transferencia de ficheros entre srvdatos y srvdatosn instalaremos el agente (cliente) de Symantec Backup Exec en este servidor. En el siguiente artículo explicamos cómo instalar Symantec Backup Exec Remote Agen (agente):

    Instalar agente de Symantec Backup Exec en WXP

    Y en este otro cómo instalar Symanctec Backup Exec y cómo crear una tarea de copia de seguridad de ficheros:

    Instalar Symantec Backup Exec en Windows Server 2003

    • Es conveniente promocionar este servidor (para realizar las pruebas oportunas antes de la transferencia), luego lo despromocionaremos (necesariamente para cambiarle el nombre de srvdatosn a srvdatos). En el siguiente artículo explicamos cómo promocionar un equipo a controlador de dominio:

    Promocionar un equipo con Windows Server 2003 a controlador de dominio

    En este otro artículo explicamos cómo despromocionar (degradar) un controlador de dominio:

    Despromoción de controlador de dominio, desinstalación Active Directory

  • Si hemos utilizado el método de compartir carpetas en srvdatos para el acceso de los usuarios a las mismas, deberemos exportar la clave de registro: HKEY_LOCAL_MACHINESYSTEM/CurrentControlSet/Services/lanmanserver/Shares de srvdatos para al final importarla a srvdatosn, de esta forma volveremos a tener todas las carpetas compartidas sin necesidad de hacerlo manualmente. En el siguiente artículo explicamos cómo compartir

 

  • A partir de este paso, es recomendable hacerlo en un momento no crítico puesto que desconectaremos los servidores de la red. Desconectaremos el servidor de copias srvbackup, servidor nuevo (srvdatosn) y servidor datos  producción (srvdatos) de la red local (siempre que sea posible) y dejarlos aislados, los tres conectados entre sí pero no a la red. De esta forma evitaremos que al hacer la copia de seguridad completa haya usuarios abriendo y modificando ficheros.
  • Puesto que utilizaremos Symantec Backup Exec para realizar la transferencia de ficheros y la configuración de seguridad (usuarios y grupos de seguridad que tendrán acceso a cada carpeta) entre srvdatos y srvdatosn, cuando hayamos aislado los tres servidores lanzaremos una copia completa de srvdatos a la unidad de cinta. Si no disponemos de un software y hardware de copia de seguridad podremos utilizar algunas herramientas para hacer la transferencia de ficheros de srvdatos a srvdatosn directamente, por ejemplo:
    • Robocopy (Robust File Copy): utilidad de Microsoft que permite copiar ficheros y configuraciones de seguridad de un servidor a otro. Permite copiar atributos NTFS, por lo que, en teoría, copiará los permisos de seguridad de las carpetas.
    • AjpdSoft Copia de Seguridad: software que permite copiar carpetas, aunque no copia permisos ni atributos NTFS, sólo carpetas y ficheros.
    • Otros programas de copia de seguridad (como Tivoli Storage Manager).
  • Tras la copia de seguridad completa, despromocionaremos el srvdatos en producción (con el comando "dcpromo"), para que no sea controlador de dominio, si no realizamos esta acción no podremos poner el nombre "srvdatos" al servidor "srvdatosn" puesto que "srvdatos" (aunque esté apagado) estará activo como miembro del dominio.
  • Apagaremos el equipo srvdatos tras copia y despromoción. Lo dejaremos intacto hasta que estemos seguros de que todo el proceso ha concluido satisfactiriamente, si hubiese algún problema, siempre podremos encenderlo, conectarlo a la red, promocionarlo a controlador de dominio y estará disponible para su funcionamiento normal.
  • Accederemos al controlador de dominio srvdominio, accederemos a "Usuarios y equipos de active directory", buscaremos en "Computers" el nombre "srvdatos", si aparece lo eliminaremos para no tener problemas a la hora de cambiar el nombre a srvdatosn.
  • Restauraremos la copia de seguridad completa que actuamente está en las cintas de la unidad de backup al srvdatosn.
  • Desconectar servidor de datos en producción (srvdatos) de la red aislada y encenderlo provisionalmente para comprobar el número de ficheros, número de carpetas y tamaño con respecto al servidor nuevo de datos (srvdatosn), tras la restauración, hemos de asegurarnos de que el proceso de transferencia de los ficheros ha sido correcto y completo.
  • Despromocionar el servidor nuevo srvdatosn (si estaba promocionado) para cambiar nombre y poner el mismo que el servidor en producción. Poner mismo nombre de red y misma IP que srvdatos. Reiniciar y comprobar que todo funciona correctamente.
  • Tras cambio de nombre, promocionar a controlador secundario de dominio. Volver a comprobar que los permisos son correctos y los recursos compartidos.
  • Conectar srvdatos (nuevo) y srvdominio a la red local.
  • Desde los equipos clientes comprobar que se accede correctamente a las carpetas compartidas y que se establece relación de confianza (no pide usuario y contraseña cuando el usuario ha iniciado sesión en un equipo con un usuario y contraseña que coincide con la del dominio Windows de srvdominio).
  • Cuando haya pasado un tiempo prudencial podremos encender el srvdatos "viejo" (sin que tenga conexión a la red) y cambiarle el nombre de red y la IP, volver a conectarlo a la red y así podremos formatear la unidad de datos para utilizarlo como servidor de datos secundario.

 

---CONTINUARÁ---

 

Artículos relacionados

 

Créditos

Artículo realizado íntegramente por Alonsojpd miembro fundador del proyecto AjpdSoft.



Nota: Revisado por AjpdSoft el 22-09-2009.
Anuncios


Enviado el Jueves, 09 julio a las 01:55:16 por ajpdsoft
Visita nuestro nuevo sitio web con programas y contenidos actualizados: Proyecto A