Automatizar la configuración con FC de una FlashArray //X en HyperV

Pues como el propio título indica, cuando hemos de hacer una configuración de una FlashArray //X en un entorno Hyper-V y mediante conexiones Fiber Channel, he creado un script en Powershell que automatiza el proceso de instalación y configuración, siguiendo las best practices que podéis encontrar en este enlace del centro de ayuda de Purestorage.

La verdad es que se podria hacer todo en entorno gráfico, pero mediante scripting es muchisimo más rápido y desatentido que no abriendo y cerrando ventanas de Windows. En todo caso, vamos a explicar los pasos de la configuración y el porqué de todo ello para, al final del post tener el script entero.

Instalación del MPIO (Multipath-I/O)

Esta característica de Windows se debe instalar para poder dotar al servidor o nodo Hyper-V distintas rutas (paths) hacia el almacenaje que presenta la FlashArray. Si uno de estas rutas (iSCSI o HBA) cae, la característica MPIO redirigirá las peticiones por otra ruta, sin que el acceso a los datos se vea afectado.

Configurar el MPIO

Una vez instalada la caracterísitca, se debe añadir el VendorId y el ProductID en un formato de 8 y 16 carácters para posteriormente, modificar los timers del MPIO para obtener el rendimiento óptimo en nuestra FlashArray. Los valores que se deben modificar son:

  • NewPathRecoveryInterval: es el tiempo que el servidor tarda en recuperar la ruta perdida. El valor por defecto es 40 y con FlahArray lo debemos cambiar a 20 segundos
  • CustomPathRecovery: es una variable booleana (1 o 0) que activa (1) o desactiva (0) la recuperación de la ruta personalizada, es decir, el primer parámetro que vamos a modificar. Con FlashArray el valor debe ser 1
  • PDORemovePeriod: un PDO es un objeto de dispositivos físicos (Physical Device Object). Este valor es el tiempo que espera el servidor a eliminar todas las rutas que han fallado hacia un PDO. El valor por defecto es 20 y con FlashArray lo debemos aumentar a 30
  • NewDiskTimeout: es el valor en segundos del tiempo de espera del disco. Este valor es el tiempo que esperará el servidor antes de marcar la solicitud E/S como fallida. En este caso se mantiene en 60 segundos, aunque la documentación de Microsoft lo establezca en 120
  • PathVerificationState: este valor nos indica si debemos verificar que el path está activo o no. Por defecto viene en Disabled y lo deberemos poner en Enabled

Configurar la política del MPIO

En este caso, y resumiendo, se refiere a como el servidor Hyper-V o host, distribuye las IOs entre las distintas rutas hacia el almacenaje. En este caso nos encontramos con que hay distintos tipos de politicas:

  • FOO: Fail Over Only
  • RR: Round Robin
  • LQD: Last Queue Depth
  • LB: Least Blocks
  • None: la que venga por defecto

En el caso de Pure Storage, la política de acceso debe ser Round Robin (RR)

Configurar la SAN Policy

Bàsciamente esto se refiere a como Windows Server determina si los discos deben montarse de forma automática cuando se detectan como nuevos en el host. En este caso si el host no forma parte de un Windows Server Failover Clustering, se debe cambiar la política de OfflineShared a OnlineAll para poner en linia los volúmenes existentes cuando se reinicie el host

Explicado todas las modificaciones que debemos hacer en un host Hyper-V, vamos a a ver como automatizarlo todo en un script. En primer lugar, los cmdlets que vamos a necesitar son los siguientes:

  • Instalación del MPIO (Multipath-I/O)

Get-WindowsFeature -Name 'Multipath-IO'

Add-WindowsFeature -Name 'Multipath-IO'

  • Configurar el MPIO

Remove-MSDSMSupportedHw -VendorId 'Vendor' -ProductId 'Product'

New-MSDSMSupportedHw -VendorId PURE -ProductId FlashArray

Set-MPIOSetting -NewPathRecoveryInterval 20 -CustomPathRecovery Enabled -NewPDORemovePeriod 30 -NewDiskTimeout 60 -NewPathVerificationState Enabled

  • Configurar la política del MPIO

Set-MSDSMGlobalDefaultLoadBalancePolicy -Policy RR

  • Configurar la SAN Policy

Set-StorageSetting -NewDiskPolicy OnlineAll

Una vez tengamos claros los cmdlets con las opciones que Pure Storage nos recomienda para los entorns HyperV vamos a construir el script. Como punto de partida, debemos pensar que hay dos reinicios del host, y por lo tanto si quieremos que sea una configuración automática y desatendida, deberemos re-arrancar el script una vez arranque el servidor y nos logueemos de nuevo. Este script seguro que no es la mejor forma de hacerlo, pero es la que suelo usar yo en instalaciones desatendidas o semi-desatendias, siendo muy fácil su gestión.

El truco radica en crear un contador ($bootcount) que irá ejecuntando las opciones del menú switch {}, generando en un directorio %\temp un fichero *ps1 con las opciones y un fichero *bat que ejecutará el script. No soy programador profesional así que si encontráis fallos, estaré encantado de recibir vuestras (constructivas) críticas.

Script:

# Create a 'temp' Folder
if (!(Get-Item C:\temp -ea ignore)) { mkdir C:\temp }

$dropperscript = 'C:\temp\FlashArrayHV_Conf.ps1'

$dropper = @'

$countfile = 'C:\temp\bootcount.txt'
$bootbatch = 'C:\ProgramData\Microsoft\Windows\Start Menu\Programs\StartUp\dropper.bat'
$dropperscript = 'C:\temp\dropper.ps1'

# Bootstrap Batch
if (!(Get-Item $bootbatch -ea ignore)) {
    "powershell -c $dropperscript`npause" | Out-File $bootbatch -Encoding 'OEM'
}

# Boot Count
if (Get-Item $countfile -ea ignore) {
    [int]$bootcount = Get-Content $countfile
    if ($bootcount -match "^\d{1,2}$") { ([int]$bootcount) ++ }
    else { $bootcount = 1 }
}
else { $bootcount = 1 }
$bootcount | Out-File $countfile

switch ($bootcount) {
    
    1 {
            Get-WindowsFeature -Name 'Multipath-IO'

            Add-WindowsFeature -Name 'Multipath-IO'
       
            Restart-Computer
                
    }
    
    2 {
            Remove-MSDSMSupportedHw -VendorId 'Vendor*' -ProductId 'Product*'
        
    New-MSDSMSupportedHw -VendorId PURE -ProductId FlashArray
            Get-MSDSMSupportedHw

            Restart-Computer
                
    }
    
    3 {
    
        Set-MPIOSetting -NewPathRecoveryInterval 20 -CustomPathRecovery Enabled -NewPDORemovePeriod 30 -NewDiskTimeout 60 -NewPathVerificationState Enabled
        Get-MPIOSetting
        Set-MSDSMGlobalDefaultLoadBalancePolicy -Policy RR
        Get-MSDSMGlobalDefaultLoadBalancePolicy

        Set-StorageSetting -NewDiskPolicy OnlineAll
        Get-StorageSetting | Select-Object NewDiskPolicy
        Restart-Computer
     }
    
    default {
        # Dropper is complete; clean up
        rm $countfile
        rm $bootbatch
        rm $dropperscript
    }
}
'@

# Drop and run Dropper

$dropper | Out-File $dropperscript -Encoding 'OEM'

Invoke-Expression $dropperscript

Nuevas cabinas de almacenaje Purestorage FlashArray //XR3 y //C

Purestorage, líder indiscutible en almacenamiento All-Flash ha presentado este 2020 su nueva versión R3 en las cabinas FlashArray //X y su cabina de almacenamiento masivo FlashArray //C.

image

Puede que el post vaya un poco atrasado, pero he decidido re-arrancar el blog (demasiado tiempo parado…) con este pedazo de producto. Para los que no conozcáis a Purestorage, se trata de un fabricante de almacenamiento flash que tiene 4 grandes productos y en donde en todos ellos garantizan un 99,999999% (¡seis nueves!) de disponibilidad, lo que significa que las cargas de trabajo siempre están dispoibles, siempre funcionan y siempre estánn protegidas, sin pérdida de rendimiento.

La familia de productos FlashArray //X para almacenamiento estructurado

FlashArray//X: Arreglo basado íntegramente en tecnología flash empresarial  integramente NVMe para la nube | Pure Storage

La familia de productos FlashBlade para almacenamiento desestructurado o como grandes contenedores de datos (Data HUB)

FlashBlade Data Sheet for File and Object Storage | Pure Storage

La familia de productos FlashArray //C para gran almacenamiento estructurado como copias de seguridad o tiers de datos

FlashArray//C Data Sheet for Hybrid Storage | Pure Storage

Cloud Block Store o almacenamiento flash en AWS (de momento…Azure está en el roadmap)

Pure Storage Cloud Block Store Goes GA - Architecting IT

A diferencia de otros fabricantes, Purestorage ha apostado des de sus inicios por tener pocos productos, pero muy muy buenos y con el tiempo, ir avanzándose a las necesidades de almacenamiento del mercado. Ah! Y sobre todo: all-flash y ahora ya NVMe-Of.

Purestorage, apuesta por el concepto Modern Data Experience:

  1. “Fast Matters”: la rapidez SI importa. El acceso al dato debe ser rápido, independientemente del tipo de dato.
  2. “Cloud Everywhere”: la facilidad de tener entornos híbridos, de poder trabajar on-cloud como si estuviéramos en on-prem o la facilidad de tener un DR en el cloud,.
  3. “Simple is smart”: Purestorage se caracteriza por se muy simple en su despliegue, configuración y posterior mantenimiento con RPO y RTO zero. Z E R O.
  4. “Subscription to Innovation”: un método nuevo y disruptivo de actualización de hardware y software que ningún fabricante hasta la fecha es capaz de ofrecer, como el concepto Evergreen.

Y todo esto se presenta en formato de cabina de almacenaje de 20 discos y 3U de espacio en el rack, o de 15 blades y 4U de espacio en el rack.

Pure Storage announces QLC-based FlashArray //C secondary storage platform  – TECHunplugged

Además, la tecnología que ofrece Purestorage está ha años luz de los que otros fabricantes pueden ofrecer

  • NVMe-Of nativo
  • Bloques de datos de 512bytes
  • Velocidades inferiores al ms
  • Capacidades de almacenaje de datos brutales
  • Herramientas cloud de monitoreo y de análisi de capacidades
  • Migraciones NDU garantizadas
  • Una sola arquitectura, miles de opciones
  • Snapshots immutables de volúmenes
  • Un 99,999999% de disponibilidad

Poco a poco iré colgando más noticias sobre este fabricante, por ejemplo, como es capaz de deduplicar tanto y tan rápido, que es el QLC que usa la FlashArray //C y porqué permite estas capacidades de almacenaje con 4ms de latencia, el monstruo FlashBlade para grandes silos de datos en un solo appliance, la replicaciones Active – Active, el sistema de snapshot… Si me vais siguiendo, os iré informando de este maravilloso producto de almacenaje.

Recuperar password en VMWare vCenter Server Appliance 6.5

Esta mañana he estado leyendo un interesantísimo artículo de Alex Samoylenko, CEO de Nova Games y escritor en el blog de StarWind, que creo que os puede ser de mucha mucha utilidad:

Recuperar el password en un vCenter Server Appliance

Si ya lo habéis instalado, veréis que este nuevo vCenter está basado en Photon (https://vmware.github.io/photon/) y para poder recuperar el password, nos explica:

¡Antes de nada hacer un Snapshot!

– Una vez que cargue el sistema operativo, pulsamos <e> para acceder al menú de edición de GRUB.

– Buscamos la sección done se inicia Linux (empieza con “linux”) i añadimos al final lo siguiente: rw init=/bin/bash

reset root password on vCenter Server Appliance

– Pulsamos F10 para continuar con la descarga

– Escribimos passwd en la línea de comandos y escribimos el password de root

– Desmontamos el sistema de ficheros con unmount /

– Reiniciamos el vCenter Server Appliance 6.5 con el comando reboot –f

– Hecho esto, el password del vCenter se reiniciarà. Una vez lo comprobéis que funciona todo, ¡recordad de eliminar el sanpshot!

Fuente | 3 useful tricks with VMware vCenter Server Appliance

VMWare: Unable to power on Virtual Machine

Buf…. maldito mensaje… y además ¡genérico! Bueno, en mi caso esta noche no podía arrancar una máquina virtual porqué me daba un error de un datastore que no estaba activo (lo peté del Datacore) pero aun estaba asociado a una máquina virtual.

El error que me daba era: Virtual disk ‘Hard disk 3’ is not accessible on the host: Unable to access file [VMFS Store Name] VM Name/VM Name.vmdk

Antes que nada, ¡calma! La solución es fácil y divertida de hacer Smile vamos a ello:

1) Primero lo que debemos hacer es (en caso de no tenerlo activado) arrancar el servicio SSH en el host donde tengamos la máquina virtual hospedada.

2) Editamos la máquina virtual y buscamos el disco vmdk que nos está dando problemas (y que muy probablemente no nos dejara remover así como así…) y vemos que en las propiedades el Virtual Device Node. Tomamos nota de él, en nuestro ejemplo SCSI (0:0) Hard disk 1

image

2) Nos conectamos mediante Putty al host y navegamos al siguiente directorio:

cd /vmfs/volumes/[Datastore donde está alojada la MV que no arranca]/[Nombre de la VM]

3) Una vez dentro, editamos el fichero vmx con el vi:

vi [Nombre de la VM].vmx

4) Vamos al final del fichero y buscamos las líneas que empiezan por el Virtual Device Node que nos hemos apuntado antes (en el ejemplo scsi 0:0) y las eliminamos. ¡Ojo! Solamente las que empiezan por scsi 0:0 o el valor que tengamos (suelen ser unas 4 o 5 líneas).

Nota: Para los que nos estáis familiarizados con el Putty, para editar el fichero pulsamos la tecla INSERT, eliminamos con SUPRIMIR y para guardar/salir pulsamos ESC y escribimos :wq!

5) Bien, cerramos el Putty y nos dirigimos a nuestro vCenter. Hacemos clic con el botón derecho sobre la máquina virtual que no arranca y le damos a Remove from Inventory. Esto lo hacemos ya que como hemos editado el fichero vmx, el host debe volver a leerlo.

6) Vamos al datastore donde tengamos la máquina virtual que no arrancaba, buscamos el fichero vmx y con el botón derecho seleccionamos Add to Inventory.

¡Y listo! Nuestra máquina virtual ya arranca pero esta vez sin el disco vmdk que nos daba problemas.

Error en xenserver SR_Backend_Failure_47

El otro día un cliente me llamó diciéndome que su sistema iba extremadamente lento. En un principio me acojoné un poco porqué este cliente funciona con Datacore SANsymphony en su versión 9.0 PSP4 (algún día hablaré del Virtual Storage) y con un sistema horrendo llamado Citrix XenServer.

Vale…supongo que ya habré herido algún sentimiento, pero pienso lo escribo: en mi particular ranking, este sistema ocupa el último puesto en cuanto a virtualización. No me gusta nada. Pero como tengo clientes que lo usan, debo saber aprender a manejarlo.

Siguiendo con lo que decía, mi cliente me llamó informándome que todo iba muy lento y cuando me conecté a la consola XenCenter, me fijé que todos los discos virtuales (a.k.a SR), habían perdido un path iSCSI hacia la V-SAN. (NOTA: los errores de multipathing son parecidos a la imagen siguiente, ya que podemos ver los dos servidores y en uno de ellos nos marca Connected y en el otro Unplugged)

¿Y ahora como los conecto? Bueno … pues tirando de manuales:

  • Hacemos clic sobre el servidor xenserver que ha perdido la conexión (NOTA: En un entorno multipathing, los servidores tienen varios caminos o path para acceder a los discos duros de la cabina) y pulsamos la pestaña “Console”

image

  • Veréis que es una consola Linux
  • En ella sacaremos primero de todo el error que nos da. Para ello, primero de todo buscamos el uuid (Universal Unique IDentifier) de nuestro SR asociado al host que ha perdido el path
[root@nuestroservidorxen]# xe sr-list
  • Cogemos el uuid del PBD (Physical Block Disk) asociado al SR anterior
[root@nuestroservidorxen]# xe pbd-list sr-uuid=<em>[Valor que nos a dado el comando anterior]</em>
  • Buscamos el parámetro que nos da el problema:
[root@nuestroservidorxen]# xe pbd-param-get param-name=other-config uuid=<em>[Valor que nos a dado el comando anterior]</em>

Bien, pues nos econtramos con un SR_Backend_Failure_47, que nos viene a decir que el servidor xenserver no se puede conectar con el recurso iSCSI. Dicho esto, debemos comprobar si realmente no existe comunicación entre el host i el recurso. Para ello haremos un ping a la interface de red del recuso iSCSI. Si NO responde, deberemos hallar el problema que muy probablemente será físico, pero si el ping responde, lo más seguro es que el problema sea lógico.

En nuestro error, el problema es lógico, ya que los ping responden sin problemas. Así mismo, para terminar de verificar el problema, podemos probar los siguientes comandos:

[root@nuestroservidorxen]# iscsiadm –m node

Con este comando veremos todos los IQNs disponibles y activos

[root@nuestroservidorxen]# iscsiadm –m session

Con este comando veremos todas la conexiones activas. Si no hay ningún error en ningún comando, entonces es que nuestro xenserver no se puede conectar al SR iSCSI (problema lógico). Pues ale, vamos a probar de conectarlos de nuevo…y lo haremos de dos formas. Pero ¡ojo! la/s máquina/s virtual/es asociada/s a este SR, deben estar apagadas.

Por consola:

root@nuestroservidorxen]# xe sr-list

[root@nuestroservidorxen]# xe pbd-list sr-uuid=<em>[Valor que nos a dado el comando anterior]</em>

[root@nuestroservidorxen]# xe pbd-plug uuid=<em>[Valor que nos a dado el comando anterior]</em>

Por el XenCenter

  1. Apagamos la/s máquina/s virtual/es asociada/s al SR que ha perdido la conexión
  2. Hacemos clic con el botón derecho sobre el SR que ha perdido la conexión y seleccionamos Detach con lo que desconectaremos el SR de todos los xenserver
  3. Hacemos clic con el botón derecho sobre el SR que hemos desconectado y seleccionamos Attach, con lo que podremos generar una conexión nueva

Si todo a ido bien, nuestro SR volverá a estar operativo con los dos (o los que sean) path iSCSI activos de nuevo.

Powershell: creación y eliminación de snapshots Hyper-V

índice

En un entorno virtual, es una muy buena práctica tener controlados los snapshots de nuestras máquinas virtuales. A diferencia de VMWare, en Hyper-V són puntos de control que se crean muy rápidamente y se consolidan de la misma forma. Es per ello que es una muy buena opción a contemplar como complemento de los backups.

En un caso concreto yo lo uso como estrategia de prevención contra Cryptolockers y ransomware varios haciendo que cada día, antes de que las empresas entren a trabajar se cree un punto de control. Para ello uso una tasca programada con el siguiente script:

Get-VM  * | checkpoint-vm -SnapshotName "[Nombre que le queramos dar] $((Get-Date).toshortdatestring())" –AsJob

Con este script en powershell, cada día se nos ejecutará un punto de control de TODAS nuestras máquinas virtuales. Podemos acotar la búsqueda o filtrar con el comando:

Get-VM –Name [Nombre de la M]

y que podremos filtrar. Por ejemplo: si todas nuestras máquinas virtuales se llaman SRV-[nombre] pero algunas son OLDSRV y solo queremos snapshots de las primeras, podemos hacer:

Get-VM SRV-*

Hecho esto, el siguiente paso es controlar cuantos snapshots queremos guardar. En mi caso solamente guardo un día puesto que como he dicho antes, es una medida de control contra los ransomware, no una backup. Para ello, uso el script siguiente:

Get-VMSnapshot –VMName [nombre_MV]* | Where-Object {$_.CreationTime -lt (Get-Date).AddDays(-1) } | Remove-VMSnapshot

Donde:

  • (Get-Date).AddDays(-1) son los días que quiero almacenar. En mi caso 1. Este valor lo podéis cambiar por el que queráis.
  • [nombre_MV]* es una string del nombre, como si fuera un sufijo. Es para filtrar.

De esta forma, puedo controlar que si nos entra algo que nos engorrine el sistema y es crítico, podemos en tan solo dos clics de ratón, volver al inicio del día. Eso si, para clientes o sistemas más críticos, uso el script varias veces al día y los elimino todos al día siguiente. La secuencia de comandos de la tasca programada es la siguiente:

powershell.exe –ExecutionPolicy Bypass –file “[ruta_del_script]”

Cambiar Win32Time a NTP

El otro día un cliente me comentó que tenía muchos problemas con la hora del servidor de dominio, y eso les daba muchos problemas. Revisando la instalación y configuración que tenía, me fijé que el PDC (Primary Domain Controller) no era el que subministraba la hora a los equipos del dominio, sino que lo hacía otro equipo mediante un ficherito bat. Esto claramente daba problemas, puesto que si el servidor que subministra la hora la pierde, arrastra con ello el resto de equipos.

¿Qué solución le propuse? Pues configurar que el PDC sirva la hora y que además no la sirva con el propio servicio Win32Time sino que lo haga como servidor NTP (mucho más estable).

Para ello, debemos ir a la siguiente clave del registro:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\W32Time\Parameters\

NTP_1

Debemos cambiar los valores siguientes:

  • El valor NtpServer les ponemos cualquier servidor NTP (en mi caso puse es.pool.ntp.org)
  • El valor Type cambiamos NT5DS a NTP

En la misma clave, pero en Config, cambiamos el valor AnnounceFlags de 10 a 5

image

Hecho esto, cerramos el regedit y abrimos un cmd en modo administrador y ejecutamos:

net stop w32time 

net start w32time

w32tm /resync /rediscover

Y testeamos la conexión con el siguiente comando:

c:\> net time \\[nombre_del_PDC] /set /y

¡Y listos! Nuestro servidor ya usará el sistema NTP para sincronizar la hora.

Error en la instalación de vSphere 6.0

Ya sé que hace mucho tiempo que no escribo nada interesante y me han llegado algún que otro mail, quejándose un poco de por qué tengo el Blog desactualizado. La verdad es que no dispongo de mucho tiempo y, cuando encuentro/soluciono alguna incidencia que quiero compartir con vosotros, pues me resulta imposible poderlo hacer. Así que, espere que (por enésima vez) pueda como mínimo escribir con cierta regularidad al respecto.

Dicho esto, os comento un reciente error (de hace algunos meses) que me daba la instalación del vSphere 6.0 como appliance. Los únicos vSphere que había instalado (en su versión 6.0) y por necesidades del guion, fueron sobre Windows Server 2012 R2 y la primera vez que lo instalé como appliance no paraba de darme errores en la instalación: Firstboot script execution error.

Pues bien, la solución la hallé aquí i la comparé en este blog, y la verdad la solución me dejó perplejo: solamente hay que añadir 1 solo registro DNS durante el proceso de instalación (a ser posible el del dominio) y si así persiste el error, añadir un registro DNS al controlador de dominio antes de la instalación (a mi me funcionó el primer paso).

Como comenta alguien en los foros de VMware…

vmware_please

Como reparar el error: “Servicio de perfil de usuario al iniciar sesion» en Windows 7

Este es un error (por desgracia) bastante frecuente en sistemas Windows Vista y Windows 7. Aunque nos parezca un «problemón» en verdad no lo es y su solución es muy simple.

NOTA: lo publico aquí porqué recientemente he visto que estos últimos días se han incrementado (sin comprender porqué) y, si puedo ser de ayuda, mejor 🙂

¡Al trapo!

  • Reiniciamos el PC/portátil en modo a prueba de fallos (Modo Seguro)
  • Ejecutamos la herramienta de registro de sistema REGEDIT pulsando la tecla Windows+R y escribiendo «REGEDIT»
  • Navegamos hacia HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\WindowsNT\CurrentVersion\ProfileList
  • Dentro veremos unos registros con un nombre del estilo S-1-5-20-93829738927189372891 y deberíamos ver uno de estos registros con una extensión .bak al final. Si hay varios de ellos, deberemos fijarnos que la numeración coincida (tomad como referencia la extensión .bak)
  • Pulsamos sobre el registro que no termina con .bak y, en el panel de la derecha si detectamos que en una de las keys pone C:\Users\Temp entonces debemos cambiar el registro.
  • Verificamos que en la que sí que termina en .bak una de las keys contiene el parámetro C:\Users\[nombre de usuarios] Si existe, este es el registro bueno.
  • Pulsamos F2 sobre el registro SIN extensión .bak y lo renombramos como .bak2
  • Pulsamos F2 sobre el registro CON extensión .bak y eliminamos la extensión
  • Pulsamos F2 sobre el registro CON extensión .bak2 y le borramos el 2
  • Cerramos el editor
  • Reiniciamos

Hecho esto, nuestro sistema iniciará sin problemas. Si por lo que sea, haciendo esto no nos arranca con normalidad, el problema será otro y deberemos averiguar de dónde viene la incidencia.