Ficheros bak no aparecen en SQL Server

Al trasladar copias de seguridad de SQL Server e intentar restaurarlas desde una ubicación diferente a la predeterminada, desde el explorador de Management Studio (SMSS) aunque sepamos que dentro de una carpeta concreta están los ficheros pueden no aparecer, si no están asignados los permisos; deberemos asignar permisos de lectura por lo menos sobre el usuario «NT SERVICE\MSSQLSERVER» del equipo local donde se ejecuta la instancia (por defecto)

Cuenta con la que se ejecuta el servicio:

Asignación de permisos a la carpeta donde se encuentran las copias de seguridad:

SYSVOL y NETLOGON en Windows Server

A la hora de migrar, actualizar o eliminar un controlador de dominio hay que tener en cuenta que una vez eliminado los equipos que todavía estén incluidos no tendrán donde verificar sus credenciales, a lo sumo la caché local de las últimas utilizadas en el equipo. El escenario habitual suele darse a la hora de añadir un nuevo servidor y repartir las tareas de verificación y roles entre varios equipos en una infraestructura de red más fiable.

Si nos encontramos ante la situación de no disponer de las carpetas indicadas en un equipo, lo más seguro es que debamos revisar donde residen los roles principales, mediante el comando:

netdom query FSMO

Con el cual obtenemos el listado de los 5 roles y la máquina en la que residen:

– Maestro de esquema
– Maestro nomecl. dominios
– PDC
– Administrador de grupos
– Maestro de infraestructura

A la hora de jubilar un controlador de dominio, debemos tener todas las funciones transferidas, si en un equipo nos tenemos las carpetas del sistema SYSVOL y NETLOGON debemos preparar un DC y eliminar el anterior con DCPROMO.EXE para forzar la sincronización de las carpetas realizaremos los siguientes pasos

En el servidor ANTIGUO:

1. Desde la consola de línea de comandos, ejecutamos:
2. Paramos el servicio «net stop ntfrs»
3. Abrimo el registro de windows REGEDIT
4. Accedemos a la clave
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\NtFrs\
Parameters\Backup\Restore\Process
Startup
5. Editamos el valor «BurFlags» DWORD introduciendo «D4»
6. Volvemos a iniciar el servicio «net start ntfrs»

En el servidor NUEVO debemos ejecutar los mismos pasos pero la clave a sustituir en este caso es:

5. Editamos el valor «BurFlags» DWORD introduciendo «D2»

Reiniciamos los servicios en los dos servidores dos veces para forzar. La sincronización de las carpetas comenzará de inmediato.

Por qué utilizar ReFS en lugar de NTFS

Inicialmente pensado para servidores de archivos, las mejoras sobre el anterior NTFS son más que notables, sobre todo en entornos virtualizados. Así como ya nadie se plantea tener datos de sistemas operativos en formato FAT, poco a poco pasará lo mismo con NTFS. Las ventajas principales son las siguientes:

– Nombre archivos y rutas largas, muy largas. La limitación de 255 caracteres pasa a más de 30.000 en formato Unicode.
– El tamaño máximo de volumen pasa de 16 exabytes, que ya era una cantidad astronómica para el uso más habitual, a más de 260.000 exabytes 
– La actualización de metadatos de los ficheros, por ejemplo un cambio de nombre, es más segura; una copia del metadatos se realiza y cuando acaba la escritura de la copia, se verifica que no hay escrituras pendientes y actualiza. Un ejemplo práctico, estamos moviendo archivos de carpeta y se van la luz, depende del momento en el que se encontrarse la copia es posible que los datos quedaran corruptos, con el nuevo sistema se reduce considerablemente esta posibilidad (las llamadas torn writes)
– Su utilización conjunta con espacios de almacenamiento (Storage spaces) mejora la fiabilidad y rendimiento, en caso de encontrar una copia corrupta se regenera de manera automática mediante sumas de comprobaciones.
– Sin utilizar espacio de almacenamiento y espejado de datos (mirroring) en el hipotético caso de encontrar problemas en una parte de los datos, este daño no afecta a todo el volumen, sigue estando disponible excepto las partes que serán eliminadas. Un ejemplo, no es necesario apagar el sistema, y/o desconectar el volumen para tener acceso exclusivo para su reparación.

Windows NT virtualizado en VMware

En ocasiones por limitaciones de presupuesto, disponibilidad de software, recursos… no es posible en la práctica real tener todos los sistemas actualizados como nos gustaría. Con estas premisas nos toca virtualizar un equipo obsoleto con nada más y nada menos que Windows NT, nos remontamos al año 1993! Aquí es donde la virtualización nos ayuda a dar una solución estable a varios problemas que nos podemos encontrar:

– Reutilización de dongles de seguridad con puerto paralelo (LPT1)
– Ejecución de código de programas para Win16

En nuestro caso concreto no era posible ejecutar el programa ni en Windows 2000, por lo que tuvimos que extraer los discos para crear un disco duro virtual a partir del físco. Una vez creada la máquina en nuestro entorno de virtualización pudimos empezar a actualizar Windows NT a la última versión disponible Service Pack 6a y los discos de instalación originales.

El siguiente paso tocaba mejorar el sistema de ficheros, desde FAT (no fat32) a NTFS dentro del entorno ya virtualizado y redimensionar las particiones originales de 2 GB, ciertamente la máquina NT se había comportado de forma más o menos estable (dentro de los esperable) todos estos años. La conversión desde el propio equipo con el comando:

convert C: /fs:ntfs


Después de un par de reinicios, ya teníamos una mejora necesaria. Aprovechamos para optimizar el funcionamiento, añadiendo un disco duro adicional al sistema para el archivo de paginación y ampliar la RAM hasta los 3 GB, más que suficiente en este caso. La máquina virtualizada en un entorno más estable y controlado empezada a notarse menos perezosa en sus inicios.

Ahora necesitábamos red, en VMware la instalación debía ser sencilla instalando los drivers y las herramientas de integración para el driver AMD PCNET Family Ethernet Adapter pero en este caso se torno algo más complicado al no encontrar los drivers en las fuentes que indica el fabricante. Tras varias pruebas con diferentes discos de instalación, encontramos 2 fuente fiables para los drivers:

– Driver de HP: SP1657
– Driver de IBM: 32p0067

En ambos casos hallamos los archivos que requeríamos para la instalación de la tarjeta de red, sin acudir a los CDs de Windos NT 4.0:

– amddlg.dll
– Amdpcn.sys
– Oemsetup.inf
– vmxnet.sys

Tras el obligado reinicio, ya disponíamos de conectividad de red a través del host:

Actualización: dependiendo de los requisitos tambien es posible virtualizar Windows NT en Hyper-v

Reinicio requerido al instalar SQL Server

En ocasiones la instalación no permite continuar por alguno de los requisitos del instalador, en este caso estar pendiente un reinicio. Después de reiniciar el equipo sigue apareciendo la imposibilidad de instalar (RebootRequiredCheck). Existen varias posibles causas, el modo de apagado/hibernación de Windows 8 puede ser una de ellas. Para «engañar» al instalador renombra temporalmente la siguiente entrada del registro:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\WindowsUpdate\Auto Update\RebootRequired