Sicherungen erstellen

Wenn Ihre Looker-Instanz von Looker gehostet wird, führt Looker automatisch regelmäßige Sicherungen für Ihre Instanz durch. Weitere Informationen finden Sie im Abschnitt Automatische Sicherungen für von Looker gehostete Instanzen.

Wenn Ihre Instanz von Kunden gehostet wird, müssen Sie Ihre eigenen Sicherungen erstellen. Weitere Informationen finden Sie im Abschnitt Sicherungsstrategie für von Kunden gehostete Instanzen.

Automatische Sicherungen für von Looker gehostete Instanzen

Von Looker gehostete Instanzen werden einmal alle 24 Stunden automatisch gesichert. Jede Sicherung enthält einen Datensatz aller Daten in der internen Datenbank der Instanz und auf dem Dateiserver der Instanz. Das sind die meisten Betriebsdaten für die Looker-Instanz. Die Daten für die Systemaktivität von Elite werden jedoch nicht gesichert.

Sicherungen werden 30 Tage lang aufbewahrt. Wenn Sie auf eine Sicherung zugreifen und sie wiederherstellen möchten, wenden Sie sich an den Support.

Sicherungsstrategie für von Kunden gehostete Instanzen

Bei von Kunden gehosteten Instanzen können Sie eine Sicherung einer einfachen Looker-Installation erstellen, indem Sie eine Kopie des Basisverzeichnisses des Looker-Nutzers (einschließlich aller normalen und verborgenen Unterverzeichnisse) erstellen. Sie können scp, rsync oder eine beliebige Standardsicherungsanwendung verwenden. Ebenso erfordert die Wiederherstellung einer einfachen Looker-Installation nur das Wiederherstellen der Dateien und das Starten von Looker.

In einigen Konfigurationen, einschließlich Clusterumgebungen, 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. Außerdem empfehlen wir, einmal pro Quartal eine Testwiederherstellung durchzuführen.

Verzeichnisstruktur

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

  • home
    • looker
    • .ssh
    • looker
      • .cache
      • .db
      • .ssl
      • .tmp
      • deploy_keys
      • log
      • models
      • models-user-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 Cache-Dateien
looker/.db Ja, es sei denn, die Backend-Datenbank wurde zu MySQL migriert Häufig Interne Datenbank von Looker
looker/.snapshots Nein Bei Update Hier werden während der Updates eine Sicherungskopie der Looker-JAR-Datei und des Verzeichnisses „.db“ gespeichert
looker/.ssl Vielleicht Selten Selbst signierte 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 Logdateien; nur erforderlich, wenn dies in Ihren Aufbewahrungsrichtlinien festgelegt ist
looker/models Nein Variable Produktionsmodelle, die aus dem Quell-Repository (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. SSL-Zertifikate, die von einer Zertifizierungsstelle signiert wurden, sollte dieses Verzeichnis zu Ihrer Sicherung hinzugefügt werden.

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

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

Obwohl dies in der Regel keine Probleme verursacht, haben einige Kunden Probleme gemeldet, wenn sie die Datei looker/.db/looker.lck in ihre Sicherungen aufnehmen. Sie können diese Datei bei Bedarf ohne Bedenken ausschließen.

Sicherung erstellen

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

Der Sicherungsprozess sollte am besten ausgeführt werden, wenn die Anwendung so wenig wie möglich verwendet wird. Berücksichtigen Sie neben der normalen Nutzerinteraktion auch die Zeiten, zu denen geplante Looks ausgeführt werden, abgeleitete Tabellen neu erstellt werden usw.

Clusterumgebungen

In Looker-Instanzen im Cluster werden die Anwendungskonfiguration, Nutzerkonten und andere Daten in einer externen MySQL-Datenbank gespeichert. 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.

Keystore-unabhängige Sicherung erstellen

Eine von Kunden gehostete Installation, die zu AES-256-GCM-Verschlüsselung migriert wurde und AWS KMS nicht verwendet, kann mit diesem Verfahren eine Sicherung ihrer Looker-Instanz erstellen, die unabhängig von ihrem lokalen Customer Master Key (CMK) ist. Dieses Verfahren bietet eine Methode zum Migrieren einer von Kunden gehosteten Instanz zu einer von Looker gehosteten Instanz, ohne einen CMK angeben zu müssen, oder zum Verschieben einer von Kunden gehosteten Instanz zu einem neuen Host, der keinen Zugriff auf denselben lokalen Keystore hat.

So erstellen Sie eine Keystore-unabhängige Sicherung:

  1. Looker beenden:

    cd looker
./looker stop

    Wenn Ihre Looker-Instanz im Cluster ausgeführt wird, müssen Sie alle Knoten beenden, bevor Sie fortfahren.

  2. Prüfen Sie, ob Ihre Looker-Instanz auf Ihren CMK zugreifen kann. Wenn Ihr CMK in einer Datei gespeichert ist, können Sie mit der Umgebungsvariable LKR_MASTER_KEY_FILE auf den Pfad Ihrer CMK-Datei verweisen:

    export LKR_MASTER_KEY_FILE=<path_to_CMK_file>

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

    export LKR_MASTER_KEY_ENV=<CMK_value>

  3. Generieren Sie eine neue Schlüsseldatei, die zum erneuten Verschlüsseln des Schlüsselverschlüsselungsschlüssels (KEK) verwendet 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 Ihrer Looker-Instanz.

Wenn Sie diese Keystore-unabhängige Sicherung wiederherstellen möchten, benötigen Sie die zuvor erstellte neue Schlüsseldatei.

Sicherungen wiederherstellen

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

Nächste Schritte

Nachdem Sie Sicherungen eingerichtet haben, können Sie dafür sorgen, dass Ihre Looker-Instanz auf die erforderlichen Dienste zugreifen kann.