[[["易于理解","easyToUnderstand","thumb-up"],["解决了我的问题","solvedMyProblem","thumb-up"],["其他","otherUp","thumb-up"]],[["很难理解","hardToUnderstand","thumb-down"],["信息或示例代码不正确","incorrectInformationOrSampleCode","thumb-down"],["没有我需要的信息/示例","missingTheInformationSamplesINeed","thumb-down"],["翻译问题","translationIssue","thumb-down"],["其他","otherDown","thumb-down"]],["最后更新时间 (UTC)：2025-08-25。"],[],[],null,["# Creating backups\n\nIf your Looker instance is Looker-hosted, Looker automatically performs regular backups for your instance. See the [Automatic backups for Looker-hosted instances](#automatic) section for more information.\n\nIf your instance is customer-hosted, then you will need to create your own backups. See the [Backup strategy for customer-hosted instances](#customer-hosted) section for more information.\n\nAutomatic backups for Looker-hosted instances\n---------------------------------------------\n\nLooker-hosted instances are backed up automatically, once every 24 hours. Each backup contains a record of all the data in the instance's internal database and in the instance's file server, which is most of the operational data for the Looker instance. However, the data for [Elite System Activity](/looker/docs/elite-system-activity) is not backed up.\n\nBackups are retained for 30 days. To access and restore a backup, [contact Support](/looker/docs/best-practices/looker-support-details).\n| **Caution:** Disabling the Looker API disables the ability to create instance backups.\n\nBackup strategy for customer-hosted instances\n---------------------------------------------\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\nFor customer-hosted instances, you can create a backup of a basic Looker installation simply by making a copy of the Looker user's home directory (including all normal and hidden subdirectories). You can use `scp`, `rsync`, or any standard backup application. Similarly, restoring a basic Looker installation just requires restoring the files and starting up\nLooker.\n\nIn some configurations, including clustered environments, Looker uses an external MySQL database for application settings, user accounts, and other data. In this case we recommend creating a backup of the MySQL database, in addition to the Looker home directory.\n\nWe highly recommend that you create these backups daily. We also recommend performing a test restoration once per quarter.\n\n### Directory structure\n\nThe standard subdirectories under the Looker user's home directory (usually **/home/looker**) are described here.\n\n- *folder* home\n - *folder* looker\n - *folder* .ssh\n - *folder* looker\n - *folder* .cache\n - *folder* .db\n - *folder* .ssl\n - *folder* .tmp\n - *folder* deploy_keys\n - *folder* log\n - *folder* models\n - *folder* models-user-1\n\n\n**SSL Note:** By default the SSL directory only contains a self-signed SSL cert, which does not need to be retained. However, if you store any additional files in this directory --- such as SSL certificates signed by a certificate authority --- this directory should be added to your backup.\n\nFiles outside of the Looker home directory, which should be added to your backup, include the following:\n\n\u003e Although it doesn't typically cause problems, some customers have reported issues if they include the `looker/.db/looker.lck` file in their backups. You can safely exclude this file if necessary.\n\n### Creating a backup\n\nYou can create a backup of your Looker instance with any standard backup application, as well as with command line tools such as rsync.\n\nIt is best for the backup process to run when the application is as lightly used as possible. In addition to normal user interaction, consider the times that scheduled Looks might be running, derived tables might be rebuilding, etc.\n\n#### Clustered environments\n\nClustered Looker instances store their application configuration, user accounts, and other data in an external MySQL database. We recommend creating a backup of this database at the same time as the Looker application. See the [MySQL documentation](https://dev.mysql.com/doc/refman/5.0/en/backup-and-recovery.html) for more details on how to back up MySQL databases.\n\n### Generating a keystore-independent backup\n\nA customer-hosted installation that has [migrated to AES-256 GCM encryption](/looker/docs/migrating-to-aes-256-gcm-encryption) and is not using AWS KMS can use this procedure to create a backup of their Looker instance that is independent of their local Customer Master Key (CMK). This procedure provides a method for migrating a customer-hosted instance to a Looker-hosted instance without having to provide a CMK, or for moving a customer-hosted instance to a new host that does not have access to the same local keystore.\n\nTo create a keystore-independent backup:\n\n1. Stop Looker:\n\n cd looker\n ./looker stop\n\n \u003e If your Looker instance is clustered, make sure to stop every node before proceeding.\n2. Ensure that your Looker instance can access your CMK. If your CMK is stored in a file, you can use the environment variable `LKR_MASTER_KEY_FILE` to point to the path of your CMK file:\n\n export LKR_MASTER_KEY_FILE=\u003cpath_to_CMK_file\u003e\n\n Or, to provide your CMK 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. Generate a new key file that will be used to re-encrypt the Key Encryption Key (KEK):\n\n ./looker generate_keyfile_for_backup \u003ckey_file_name\u003e\n\n Where `\u003ckey_file_name\u003e` is the name you want to use for the file that Looker will create and then use to write the new key.\n\n The contents of the new key file will look like: \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.\n4. Use the new key file to create a new key entry in Looker's internal database:\n\n ./looker keystore_independent_recrypt \u003ckey_file_name\u003e\n\n Where `\u003ckey_file_name\u003e` is the key file created earlier.\n\n This decrypts the KEK in the internal database using the CMK, then re-encrypts the KEK with the new key and persists that encrypted value to the database.\n5. Create a backup of your Looker instance using your regular backup method.\n\nTo [restore this keystore-independent backup](/looker/docs/restoring-backups#restoring_a_keystore-independent_backup), you will need the new key file created earlier.\n\n### Restoring backups\n\nTo restore a backup of your Looker instance, see the [Restoring backups](/looker/docs/restoring-backups) documentation page.\n\nNext steps\n----------\n\nAfter you have set up backups, you will be ready to [ensure that your Looker instance can access necessary services](/looker/docs/outbound-port-requirements)."]]
