En mi nuevo trabajo, tengo un servidor de producción con las siguientes cualidades:
- Windows Server 2003, hardware antiguo
- Base de datos absolutamente vital
- No hay copias de seguridad de ningún tipo
- Todos en la empresa tienen derechos de administrador completos, las contraseñas se almacenan en un archivo .txt en el recurso compartido global
- Sin instaladores, excepto el sistema operativo
- La máquina misma está sentada en un estante de madera a 5 pies del suelo contra una pared externa con tráfico frecuente de camiones al otro lado; el estante ya está doblado por la carga constante
- No se ha reiniciado en $ DEITY, sabe cuánto tiempo, mi predecesor ni siquiera estaba seguro de si sobreviviría; por supuesto, no se han aplicado actualizaciones, nunca
- UPS está instalado, pero como todo está conectado, duraría 10 minutos como máximo
- Sin piezas de repuesto ni presupuesto de hardware.
¿Cómo hago una copia de seguridad completa con un impacto mínimo en el servidor? No estoy seguro de lo cerca que está de un colapso total. Por lo que sé, enchufar un dispositivo USB podría matar a la compañía, y por supuesto será todo culpa mía, ya que "estaba funcionando bien antes de que lo tocara".
La solución ideal sería una máquina virtual, por lo que también tengo un entorno de prueba (separado, por supuesto).
Actualización: después de una larga conversación con el jefe, ahora tengo permiso para hacer lo que creo que es mejor a largo plazo, por lo que ahora hay esperanza. Además, descubrí que la mayoría de los datos dignos de copia de seguridad se almacenan en las máquinas del cliente en directorios bien ocultos, el disco duro del servidor no es lo suficientemente grande, y aunque todavía no tengo un presupuesto de hardware, hay otra caja antigua que ha dejado de usarse porque todo el malware lo empantanó. Suspiro.
.txt
en el recurso compartido global.Respuestas:
Las respuestas técnicas de todos los demás son perfectas, pero debe considerar otra opción; salir.
La razón por la que sugiero esto es porque si su empresa valora su TI tan poco, probablemente valore aún menos sus esfuerzos. Cuando, y quiero decir, cuándo, este sistema mata sus negocios, te culparán por completo, te despedirán y maldecirán donde puedan, tal vez incluso te persigan por algún tipo de daño. Podría sugerirle que se siente con ellos para explicar su falta de inversión y la urgente necesidad de hacerlo, pero por lo que ha dicho, no estoy seguro de que lo escuchen.
Entonces, mi sugerencia es buscar un lugar que merezca el profesionalismo que claramente le interesa ofrecer, no creo que le resulte difícil. Buena suerte.
fuente
Agradable.
Recomendaría VMware Converter ( http://www.vmware.com/products/converter/ ). Es gratis, hará de físico a virtual (p2v), y lo he usado para hacer algo similar.
El único problema puede ser que puede ser sensible a la versión del parche del objetivo. Te deseo mucha suerte.
Solo puedo recomendar usar esto como un incentivo para nunca permitir que un servidor entre en esta situación. Y sinceramente espero que su predecesor no esté en condiciones de permitir que algo como esto vuelva a suceder.
EDITAR: Parece que sabes que esta es una mala situación, lo cual es genial. Si desea continuar perfeccionando sus habilidades, le recomiendo que tome una copia de The Practice of System and Network Administration. Es Serverfault aprobado
fuente
Parece que estás bastante jodido; toda la situación es absolutamente horrible desde el punto de vista de TI.
Probablemente haría todo lo posible para obtener otro servidor, actualizarlo, instalar el software de la base de datos y asegurarlo con los permisos adecuados y obtener una buena rutina de respaldo para el nuevo servidor y luego migrar la base de datos anterior al nuevo sistema.
Para responder a su pregunta, si va a virtualizarla, hay un convertidor VMWare que puede hacerlo, pero aún tiene que arriesgarse a hacer esto. También debe tener en cuenta algunos elementos de cambio de hardware que ocurren en la conversión y hacer que se prueben, así como también tener en cuenta que la base de datos y el servidor vital están "inactivos" durante la transición.
Esto tampoco soluciona los problemas de seguridad (¿cómo evita que algún otro empleado elimine "accidentalmente" la base de datos vital?) Ni soluciona la falta de un problema de rutina de respaldo adecuado ...
Para responder su pregunta con mayor precisión, puede actualizarla con cualquiera de los diversos programas comerciales de respaldo que generalmente implicarán ejecutar algún tipo de programa de agente que sepa cómo manejar archivos abiertos. Sin embargo, aún implicará reinicios, por lo que existe un riesgo por la descripción del sistema que proporcionó. No dijo qué estaba ejecutando esta base de datos, así que no sé si hay una preocupación específica relacionada con la configuración del software.
Tendría la tentación de comenzar programando un momento para apagar el servidor e imágenes de toda la unidad desde un CD de arranque, ya sea usando algo de código abierto (disco de arranque de Linux y DD a otro medio o usando partimage, pero no hay garantía de que estos se restaurará correctamente en otra unidad sin probarlo) o comercial (acronis o ghost, por ejemplo). Una vez que tenga una imagen de la unidad, al menos tiene la posibilidad de poder restaurar o extraer datos si fuera necesario.
Sea lo que sea este negocio, si le dicen que los datos y el sistema son absolutamente vitales y necesarios, pero permiten que todos los usuarios del negocio tengan acceso completo a los datos y posiblemente eliminen o dañen los datos (intencionalmente o no) y sin disposiciones para proteger adecuadamente los datos o brindarle soporte cuando dice que debe hacerse, entonces no es absolutamente necesario ni vital. Si honestamente creen que lo es y lo tratan así, es posible que realmente desee considerar esto como una posición temporal, ya que va a tener un viaje difícil.
fuente
Sí, use el convertidor VMware VM para convertirlo en una "infraestructura VM", prepare un nuevo disco duro en su servidor con VMWare ESXi (actualmente en la versión 4.0 y es gratis) como hiperisor, hágalo RAID (hardware) con nivel 6 o 10 si se le permite financieramente como ESXi dun do SW RAID. Compruebe si su controlador RAID es uno de los que funciona con ESXi aquí .
Luego puede usar VSphere para monitorearlo de forma remota.
Tenga en cuenta que fui golpeado por el problema de activación de la resurrección después de convertir una máquina WS2K3 (oem std) ya que detectó que el HW se modificó significativamente, siempre que su ventana no sea una versión oem, creo que estará bien.
Dado que no se permite ningún presupuesto, es posible que deba renunciar a su propio disco duro para la nueva configuración de VM y, a cambio, puede recuperar el que está en su servidor.
Pero también debe prepararse para las consecuencias, es decir, todos los dedos pueden comenzar a apuntar a su esquina desde el momento en que configura el nuevo servidor porque acaba de entrar en él. Lo hice hace solo una semana y todavía estoy buscando una buena solución de respaldo tanto para las máquinas virtuales como para la base de datos.
Buena suerte :-)
EDITAR: Para la copia de seguridad ... vSphere tiene un navegador de almacén de datos que le permite hacer una copia de los archivos de VM en su máquina local dado que está ejecutando vSphere desde su máquina local. Realice una instantánea de la VM en ejecución (use el modo de reposo si la situación lo permite) que libere los bloqueos de los archivos de VM antes de copiar, o bien, puede usar el navegador web para obtener acceso a su servidor ESXi-ed y ftp desde allí.
Una cosa a tener en cuenta es que la duración de extraer todos los archivos VM a través de la red puede ralentizar un poco su servidor.
fuente