Mit Sammlungen den Überblick behalten
Sie können Inhalte basierend auf Ihren Einstellungen speichern und kategorisieren.
Informationen zum Erstellen von Looker-Sicherungen finden Sie auf der Dokumentationsseite Sicherungen erstellen.
Wenn Sie eine vom Kunden gehostete Looker-Instanz auf einem neuen Host wiederherstellen möchten, führen Sie nur die folgenden Schritte der Looker-Installationsanleitung aus:
Prüfen Sie, ob der neue Server die Mindestanforderungen erfüllt.
Aktivieren Sie ntpd oder chronyd.
Erstellen Sie den Nutzer, die Gruppe und das Basisverzeichnis looker.
Überspringen Sie das Herunterladen der Looker-Anwendung und alle verbleibenden Installationsschritte.
Sobald der neue Host eingerichtet ist:
Stellen Sie die Dateien aus der Sicherung wieder her.
So starten Sie Looker:
sudo su - looker
cd looker
./looker start
Clusterumgebungen
So stellen Sie die MySQL-Datenbank für eine Clusterumgebung wieder her:
Beenden Sie alle laufenden Lookers im Cluster.
Stellen Sie die Datenbank wieder her.
Starten Sie die Looker-Instanzen einzeln.
Weitere Informationen zum Wiederherstellen von MySQL-Datenbanken finden Sie in der MySQL-Dokumentation.
Nachdem Sie eine schlüsselspeicherunabhängige Sicherung wiederhergestellt haben, gehen Sie so vor, um den KEK zu entschlüsseln, mit dem neuen lokalen Schlüsselspeicher neu zu verschlüsseln und den Schlüsseleintrag in der internen Datenbank zu aktualisieren:
So beenden Sie Looker:
cd looker
./looker stop
Wenn Looker geclustert ist, müssen Sie jeden Knoten anhalten, bevor Sie fortfahren.
Wenn noch Knoten ausgeführt werden, wenn Sie später den Befehl restore_dr_backup ausführen, schlägt der Befehl fehl und Sie erhalten die Meldung „Es gibt noch andere aktive Knoten, die mit dieser Looker-Backend-Datenbank verbunden sind. Wenn Looker innerhalb der letzten Minute heruntergefahren wurde, versuchen Sie es bald noch einmal. Andernfalls prüfen Sie, ob alle Knoten im Cluster heruntergefahren sind.“
Achten Sie darauf, dass Looker auf den CMEK zugreifen kann, der für den lokalen Schlüsselspeicher des Speicherorts verwendet wird, an dem Sie Looker wiederhergestellt haben. Wenn der CMEK des Wiederherstellungsorts in einer Datei gespeichert ist, können Sie mit der Umgebungsvariablen LKR_MASTER_KEY_FILE auf den Pfad der CMEK-Datei verweisen:
export LKR_MASTER_KEY_FILE=<path_to_CMK_file>
Wenn Sie die CMK des Wiederherstellungsorts direkt in einer Umgebungsvariablen angeben möchten, können Sie die Umgebungsvariable LKR_MASTER_KEY_ENV verwenden:
export LKR_MASTER_KEY_ENV=<CMK_value>
Aktualisieren Sie die interne Datenbank:
./looker restore_dr_backup <path_to_CMK_file>
Dabei ist <path_to_CMK_file> der Pfad und Dateiname der Schlüsseldatei im Klartext, die beim Erstellen der unabhängigen Sicherung im Schlüsselspeicher erstellt wurde. Die Schlüsseldatei hat folgendes Format:
Dabei ist der Wert für dbmk ein Base64-codierter 256-Bit-Verschlüsselungsschlüssel und backup_uid ein eindeutiger Name, der beim Speichern des Schlüssels in der Datenbank verwendet wird.
Nachdem Sie die interne Datenbank von Looker aktualisiert haben, können Sie Looker wie gewohnt starten. Sobald Looker ausgeführt wird, empfehlen wir, die Schlüsseldatei im Klartext zu löschen, die zum Erstellen der unabhängigen Sicherung des Schlüsselspeichers verwendet wurde.
[[["Leicht verständlich","easyToUnderstand","thumb-up"],["Mein Problem wurde gelöst","solvedMyProblem","thumb-up"],["Sonstiges","otherUp","thumb-up"]],[["Schwer verständlich","hardToUnderstand","thumb-down"],["Informationen oder Beispielcode falsch","incorrectInformationOrSampleCode","thumb-down"],["Benötigte Informationen/Beispiele nicht gefunden","missingTheInformationSamplesINeed","thumb-down"],["Problem mit der Übersetzung","translationIssue","thumb-down"],["Sonstiges","otherDown","thumb-down"]],["Zuletzt aktualisiert: 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."]]
