Organiza tus páginas con colecciones
Guarda y categoriza el contenido según tus preferencias.
Para obtener información sobre cómo crear copias de seguridad de Looker, consulta la página de documentación Cómo crear copias de seguridad.
Para restablecer una instancia de Looker alojada por el cliente en un host nuevo, completa solo estos pasos de las instrucciones de instalación de Looker:
Verifica que el nuevo servidor cumpla con las especificaciones mínimas.
Habilita ntpd o chronyd.
Crea el usuario, el grupo y el directorio principal de observador.
Omite la descarga de la aplicación de Looker y todos los pasos de instalación restantes.
Una vez que el host nuevo esté preparado, haz lo siguiente:
Restablece los archivos de la copia de seguridad.
Inicia Looker:
sudo su - looker
cd looker
./looker start
Entornos agrupados
Para restablecer la base de datos de MySQL en un entorno de clúster, sigue estos pasos:
Detén todos los Lookers en ejecución en el clúster.
Restablece la base de datos.
Inicia las instancias de Looker de a una.
Consulta la documentación de MySQL para obtener más detalles sobre cómo restablecer bases de datos de MySQL.
Cómo restablecer una copia de seguridad independiente del almacén de claves
Después de restablecer una copia de seguridad independiente del almacén de claves, sigue este procedimiento para desencriptar la KEK, volver a encriptarla con el nuevo almacén de claves local y actualizar la entrada de clave en la base de datos interna:
Detén Looker:
cd looker
./looker stop
Si Looker está agrupado, asegúrate de detener todos los nodos antes de continuar.
Si algún nodo sigue ejecutándose cuando, más adelante, emites el comando restore_dr_backup, este fallará con el mensaje "Hay otros nodos activos conectados a esta base de datos de Looker de backend. Si Looker se cerró en el último minuto, vuelve a intentarlo en breve. De lo contrario, verifica que todos los nodos del clúster estén cerrados".
Asegúrate de que Looker pueda acceder a la CMK que se usa para el almacén de claves local de la ubicación en la que restableciste Looker. Si la CMK de la ubicación de restablecimiento se almacena en un archivo, puedes usar la variable de entorno LKR_MASTER_KEY_FILE para apuntar a la ruta de acceso del archivo de CMK:
export LKR_MASTER_KEY_FILE=<path_to_CMK_file>
O bien, si deseas proporcionar la CMK de la ubicación de restablecimiento directamente en una variable de entorno, puedes usar la variable de entorno LKR_MASTER_KEY_ENV:
export LKR_MASTER_KEY_ENV=<CMK_value>
Actualiza la base de datos interna:
./looker restore_dr_backup <path_to_CMK_file>
En el ejemplo anterior, <path_to_CMK_file> es la ruta de acceso y el nombre del archivo de clave de texto sin formato que se creó cuando se realizó la copia de seguridad independiente del almacén de claves. El archivo de clave tiene el siguiente formato:
donde el valor de dbmk es una clave de encriptación de 256 bits codificada en Base64 y backup_uid es un nombre único que se usa cuando se guarda la clave en la base de datos.
Después de actualizar la base de datos interna de Looker, puedes iniciar Looker de forma normal. Una vez que Looker esté en ejecución, te recomendamos que borres el archivo de clave de texto simple que se usó para crear la copia de seguridad independiente del almacén de claves.
[[["Fácil de comprender","easyToUnderstand","thumb-up"],["Resolvió mi problema","solvedMyProblem","thumb-up"],["Otro","otherUp","thumb-up"]],[["Difícil de entender","hardToUnderstand","thumb-down"],["Información o código de muestra incorrectos","incorrectInformationOrSampleCode","thumb-down"],["Faltan la información o los ejemplos que necesito","missingTheInformationSamplesINeed","thumb-down"],["Problema de traducción","translationIssue","thumb-down"],["Otro","otherDown","thumb-down"]],["Última actualización: 2025-07-31 (UTC)"],[],[],null,["# Restoring backups\n\n| **Warning:** If your instance is customer-hosted, do not modify LookML files directly on the filesystem of your instance. This can cause unexpected errors in your Git workflow. To make changes to your LookML files, follow the steps at [Using version control and deploying](/looker/docs/version-control-and-deploying-changes).\n\nTo learn about *creating* Looker backups, see the [Creating backups](/looker/docs/creating-backups) documentation page.\n\nTo *restore* a customer-hosted Looker instance to a new host, complete only these steps of the [Looker installation instructions](/looker/docs/installing-looker-application):\n\n- Verify that the new server complies with the minimum server specifications.\n- Enable ntpd or chronyd.\n- Create the **looker** user, group, and home directory.\n- Skip downloading the Looker application and all remaining installation steps.\n\nOnce the new host is prepared:\n\n- Restore the files from backup.\n- Start Looker:\n\n sudo su - looker\n cd looker\n ./looker start\n\nClustered environments\n----------------------\n\nTo restore the MySQL database for a clustered environment:\n\n- Stop any running Lookers in the cluster.\n- Restore the database.\n- Start the Looker instances one at a time.\n\nSee the [MySQL documentation](https://dev.mysql.com/doc/refman/5.0/en/backup-and-recovery.html) for more details on how to restore MySQL databases.\n\nRestoring a keystore-independent backup\n---------------------------------------\n\nCustomer-hosted installations that have [migrated to AES-256 GCM encryption](/looker/docs/migrating-to-aes-256-gcm-encryption) and [generated a keystore-independent backup](/looker/docs/creating-backups#generating_a_keystore-independent_backup) need to update Looker's internal database after performing a restore.\n\nAfter restoring a keystore-independent backup, follow this procedure to decrypt the KEK, re-encrypt it using the new local keystore, and update the key entry in the internal database:\n\n1. Stop Looker:\n\n cd looker\n ./looker stop\n\n If Looker is clustered, make sure to stop every node before proceeding.\n\n If any nodes are still running when you later issue the `restore_dr_backup` command, the command will fail with the message, \"There are other live nodes connected to this backend Looker database. If Looker was shutdown within the last minute, try again shortly, otherwise verify all nodes in the cluster are shut down.\"\n2. Ensure that Looker can access the CMK used for the local keystore of the location where you restored Looker. If the CMK of the restore location is stored in a file, you can use the environment variable `LKR_MASTER_KEY_FILE` to point to the path of the CMK file:\n\n export LKR_MASTER_KEY_FILE=\u003cpath_to_CMK_file\u003e\n\n or, if you want to provide the CMK of the restore location directly in an environment variable, you can use the `LKR_MASTER_KEY_ENV` environment variable: \n\n export LKR_MASTER_KEY_ENV=\u003cCMK_value\u003e\n\n3. Update the internal database:\n\n ./looker restore_dr_backup \u003cpath_to_CMK_file\u003e\n\n where `\u003cpath_to_CMK_file\u003e` is the path and filename of the plain text key file created when the keystore-independent backup was made. The key file has the following format: \n\n {\"dbmk\":\"vr1LUwO3q6weY8iS3JykVljSjiD4m6eGk227Cs7Qu9Q=\\n\",\"backup_uid\":\"XCXvRa38mNeqT6+HRBCo2Q==\"}\n\n where the value for `dbmk` is a Base64 encoding 256-bit encryption key and `backup_uid` is a unique name used when saving the key to the database.\n\nAfter you have updated Looker's internal database, you can start Looker normally. Once Looker is running, we recommend that you delete the plaintext key file used to create the keystore-independent backup."]]
