Sicherungen erstellen

Für von Kunden gehostete Instanzen können Sie eine Sicherung einer Looker-Basisinstallation erstellen, indem Sie einfach eine Kopie des Basisverzeichnisses des Looker-Benutzers (einschließlich aller normalen und verborgenen Unterverzeichnisse) erstellen. Dies kann über scp, rsync oder eine beliebige Standardsicherungsanwendung erfolgen. Ebenso müssen zum Wiederherstellen einer Looker-Basisinstallation nur die Dateien wiederhergestellt und gestartet werden. Looker

In einigen Konfigurationen, einschließlich geclusterter Umgebungen, verwendet Looker eine externe MySQL-Datenbank für Anwendungseinstellungen, Nutzerkonten und andere Daten. In diesem Fall empfehlen wir, zusätzlich zum Looker-Basisverzeichnis eine Sicherung der MySQL-Datenbank zu erstellen.

Wir empfehlen dringend, diese Sicherungen täglich zu erstellen. Wir empfehlen außerdem, die Testwiederherstellung einmal pro Quartal durchzuführen.

Verzeichnisstruktur

Hier werden die Standardunterverzeichnisse im Basisverzeichnis des Looker-Nutzers (in der Regel /home/looker) beschrieben.

  • Startseite
    • Looker
    •  .ssh
    • Looker
      • (Cache)
      •  .db
      • .ssl
      •  .tmp
      • deploy_keys
      • -Protokoll
      • Modelle
      • Modelle-Nutzer-1
Verzeichnis Sicherung erforderlich Häufigkeit ändern Beschreibung
.ssh Ja Selten SSH-Schlüssel, die für die Authentifizierung bei Git für LookML-Projekte verwendet werden, die mit Looker 4.6 oder älter erstellt wurden
looker/.cache Nein Häufig Temporäre Cachedateien
looker/.db Ja, es sei denn, die Backend-Datenbank wurde zu MySQL migriert. Häufig Interne Looker-Datenbank
looker/.snapshots Nein Bei Aktualisierung Hier wird während der Updates eine Sicherungskopie des Looker-JAR- und .db-Verzeichnisses gespeichert.
looker/.ssl Vielleicht Selten Selbstsignierte SSL-Zertifikate (siehe Hinweis)
looker/.tmp Nein Häufig Temporäre Dateien
looker/deploy_keys Ja Selten SSH-Schlüssel, die für die Authentifizierung bei Git für LookML-Projekte verwendet werden, die mit Looker 4.8 oder höher erstellt wurden
looker/log Vielleicht Häufig Protokolldateien; nur erforderlich, wenn dies von Ihren Aufbewahrungsrichtlinien gefordert wird
looker/models Nein Variable Produktionsmodelle, die aus dem Quellrepository (in der Regel GitHub) kopiert wurden
looker/models-user-* Ja Variable Die Entwicklungsmodelle der einzelnen Nutzer werden in separaten Verzeichnissen mit der ID-Nummer des Nutzers gespeichert.

SSL-Hinweis:Standardmäßig enthält das SSL-Verzeichnis nur ein selbst signiertes SSL-Zertifikat, das nicht aufbewahrt werden muss. Wenn Sie jedoch zusätzliche Dateien in diesem Verzeichnis speichern, z. B. von einer Zertifizierungsstelle signierte SSL-Zertifikate, sollte dieses Verzeichnis Ihrem Back-up hinzugefügt werden.

Dateien außerhalb des Looker-Basisverzeichnisses, die Ihrer Sicherung hinzugefügt werden sollten, sind:

Verzeichnis Sicherung erforderlich Häufigkeit ändern Beschreibung
/etc/init.d/looker Ja Selten Systemstartskript für Looker
SSL-Zertifikate Ja Selten Wenn Sie SSL-Zertifikate verwenden, müssen alle erforderlichen Dateien enthalten sein.

Normalerweise verursacht das keine Probleme, aber einige Kunden haben Probleme gemeldet, wenn sie die Datei looker/.db/looker.lck in ihren Sicherungen verwenden. Sie können diese Datei bei Bedarf ausschließen.

Looker-Sicherung erstellen

Sie können eine Looker-Sicherung mit einer beliebigen Standardsicherungsanwendung sowie mit Befehlszeilentools wie rsync erstellen.

Der Sicherungsprozess sollte nur dann ausgeführt werden, wenn die Anwendung so wenig wie möglich genutzt wird. Berücksichtigen Sie neben den normalen Nutzerinteraktionen auch Zeiten, zu denen geplante Looks ausgeführt werden oder abgeleitete Tabellen neu erstellt werden.

Geclusterte Umgebungen

Geclusterte Lookers speichern ihre Anwendungskonfiguration, Nutzerkonten und andere Daten in einer externen MySQL-Datenbank. Wir empfehlen, gleichzeitig mit der Looker-Anwendung eine Sicherung dieser Datenbank zu erstellen. Weitere Informationen zum Sichern von MySQL-Datenbanken finden Sie in der MySQL-Dokumentation.

Schlüsselspeicherunabhängige Sicherung erstellen

Eine vom Kunden gehostete Installation, die zur AES-256-GCM-Verschlüsselung migriert wurde und nicht AWS KMS verwendet, kann mit diesem Verfahren eine Sicherung ihrer Looker-Instanz erstellen, die unabhängig von ihrem lokalen Customer Master Key (CMK) ist. So können Kunden mit einer selbst gehosteten Lösung zu einer von Looker gehosteten Installation wechseln, ohne ihre CMK angeben zu müssen, oder eine vom Kunden gehostete Installation auf einen neuen Host verschieben, der keinen Zugriff auf denselben lokalen Schlüsselspeicher hat.

So erstellen Sie eine speicherortunabhängige Sicherung:

  1. Beenden Sie Looker:

    cd looker
    ./looker stop
    

    Wenn Looker geclustert ist, müssen Sie jeden Knoten anhalten, bevor Sie fortfahren.

  2. Achten Sie darauf, dass Looker auf Ihre CMK zugreifen kann. Wenn der CMK in einer Datei gespeichert ist, können Sie die Umgebungsvariable LKR_MASTER_KEY_FILE verwenden, um auf den Pfad Ihrer CMK-Datei zu verweisen:

    export LKR_MASTER_KEY_FILE=<path_to_CMK_file>
    

    Alternativ können Sie die CMK direkt in einer Umgebungsvariablen angeben. Verwenden Sie dazu die Umgebungsvariable LKR_MASTER_KEY_ENV:

    export LKR_MASTER_KEY_ENV=<CMK_value>
    
  3. Generieren Sie eine neue Schlüsseldatei, mit der der Schlüsselverschlüsselungsschlüssel (Key Encryption Key, KEK) neu verschlüsselt wird:

    ./looker generate_keyfile_for_backup <key_file_name>
    

    Dabei ist <key_file_name> der Name, den Sie für die Datei verwenden möchten, die von Looker erstellt und dann zum Schreiben des neuen Schlüssels verwendet wird.

    Der Inhalt der neuen Schlüsseldatei sieht so aus:

    {"dbmk":"vr1LUwO3q6weY8iS3JykVljSjiD4m6eGk227Cs7Qu9Q=\n","backup_uid":"XCXvRa38mNeqT6+HRBCo2Q=="}
    

    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.

  4. Verwenden Sie die neue Schlüsseldatei, um einen neuen Schlüsseleintrag in der internen Datenbank von Looker zu erstellen:

    ./looker keystore_independent_recrypt <key_file_name>
    

    Dabei ist <key_file_name> die zuvor erstellte Schlüsseldatei.

    Dadurch wird der KEK in der internen Datenbank mit dem CMK entschlüsselt, dann mit dem neuen Schlüssel neu verschlüsselt und der verschlüsselte Wert in der Datenbank gespeichert.

  5. Erstellen Sie mit Ihrer regulären Sicherungsmethode eine Sicherung von Looker.

Um diese schlüsselspeicherunabhängige Sicherung wiederherzustellen, müssen Sie die zuvor erstellte neue Schlüsseldatei erstellen.

Sicherungen wiederherstellen

Informationen zum Wiederherstellen einer Looker-Sicherung finden Sie auf der Dokumentationsseite Sicherungen wiederherstellen.

Nächste Schritte

Nachdem Sie die Sicherungen eingerichtet haben, können Sie prüfen, ob Looker auf die erforderlichen Dienste zugreifen kann.