Mit Sammlungen den Überblick behalten
Sie können Inhalte basierend auf Ihren Einstellungen speichern und kategorisieren.
Auf dieser Seite wird beschrieben, wie Sie ein Sicherungs-Repository für Clusterarbeitslasten in Google Distributed Cloud (GDC) Air-Gap erstellen.
Ein Sicherungs-Repository ist ein kompatibler Speicherort für Ihre Sicherungen. In einem Sicherungs-Repository werden auch Aufzeichnungen von Sicherungen, Sicherungsplänen, Wiederherstellungsplänen und Wiederherstellungen gespeichert.
Hinweise
Zum Erstellen eines Sicherungs-Repositorys benötigen Sie Folgendes:
Ein kompatibler Endpunkt ist verfügbar.
Ein zuvor erstellter Bucket, der als Sicherungsrepository verwendet werden soll.
Organisationsadministrator für Sicherungen: Verwaltet Sicherungsressourcen wie Sicherungs- und Wiederherstellungspläne in Nutzerclustern. Bitten Sie Ihren IAM-Administrator der Organisation, Ihnen die Rolle „Organisations-Backup-Administrator“ (organization-backup-admin) zuzuweisen. Weitere Informationen finden Sie unter Rollendefinitionen.
Repository erstellen
Erstellen Sie ein Repository über die GDC Console oder die API.
Console
Melden Sie sich in der GDC-Konsole an.
Klicken Sie im Navigationsmenü auf Sicherung für Cluster. Achten Sie darauf, dass in der Projektauswahl kein Projekt ausgewählt ist.
Klicken Sie auf Repository erstellen.
Geben Sie einen Repository-Namen ein. Die Beschreibung ist optional.
Wählen Sie in der Liste Hauptcluster (Lese-/Schreibzugriff) einen Cluster aus.
Wählen Sie in der Liste Verknüpfte Cluster (schreibgeschützt) die verknüpften Cluster aus.
Geben Sie im Feld S3-URI-Endpunkt einen Endpunkt mit dem vollständig qualifizierten Domainnamen Ihrer Objektspeicherwebsite ein:.
Geben Sie im Feld Bucket-Name den Namen des voll qualifizierten Namens des Buckets ein. Dieser ist im Status der benutzerdefinierten Ressource des GDC-Buckets zu finden.
Geben Sie im Feld Bucket-Region die Region ein, in der der Bucket erstellt wurde.
Geben Sie in die Liste Access Key ID (Zugriffsschlüssel-ID) die Zugriffsschlüssel-ID ein.
Geben Sie im Feld Zugriffsschlüssel den Zugriffsschlüssel ein.
Klicken Sie auf Erstellen.
API
Wenn Sie die APIs für Sicherung und Wiederherstellung verwenden möchten, müssen Sie eine gültige benutzerdefinierte ClusterBackupRepository-Ressource als Speicherort für Ihre Sicherungen konfigurieren und die erforderlichen Anmeldedaten angeben.
Fügen Sie eine benutzerdefinierte ClusterBackupRepository-Ressource hinzu, um diese Anmeldedaten zu verwenden, und wenden Sie die neue Ressource auf den Management API-Server an.
Sicherungs-Repositories sind clusterbezogen:
Ein NamespacedName, das auf das Secret verweist, das die Anmeldedaten für den Zugriff auf endpoint enthält.
endpoint
Der voll qualifizierte Domainname für das Speichersystem.
type
Der Typ des Sicherungs-Repositorys. Nur der Typ S3 wird unterstützt.
s3Options
Die Konfiguration für den S3-Endpunkt. Dies ist erforderlich, wenn typeS3 ist.
bucket: Der voll qualifizierte Name des Buckets, der im Status der benutzerdefinierten GDC-Bucket-Ressource zu finden ist.
region: die Region des angegebenen Endpunkts. Die Region ist spezifisch für das Speichersystem.
forcePathStyle: Mit dieser Option wird festgelegt, ob für Objekte Pfadstil-URLs erzwungen werden sollen.
importPolicy
Legen Sie einen der folgenden Werte fest:
ReadWrite: Dieses Repository kann zum Planen oder Erstellen von Sicherungen, Sicherungsplänen und Wiederherstellungen verwendet werden.
ReadOnly: Dieses Repository kann nur zum Importieren und Anzeigen von Sicherungen verwendet werden. In diesem Repository können keine neuen Sicherungen oder Ressourcen erstellt werden. Bei der Wiederherstellung können jedoch schreibgeschützte Sicherungen verwendet und referenziert werden. Es gibt keine Einschränkung, wie oft ein Sicherungs-Repository als ReadOnly. verwendet werden kann.
Importrichtlinien für Sicherungs-Repositorys
Alle Cluster müssen mindestens ein ReadWrite-Repository haben, damit die Sicherungs- und Wiederherstellungsfunktionen verwendet werden können. ReadOnly-Repositories sind optional, haben kein Limit und werden verwendet, um Einblick in andere Clustersicherungen für clusterübergreifende Wiederherstellungen zu erhalten.
ReadOnly-Repositories können nicht als Speicherorte für zusätzliche Sicherungen oder für Sicherungspläne in dem Cluster verwendet werden, in den sie importiert wurden.
Wenn Sie ein Repository als ReadWrite importieren, wird das Repository für diesen Cluster beansprucht. Andere Cluster können das Repository dann nicht mehr als ReadWrite importieren. Nach dem Import eines ReadWrite-Repositorys werden alle Datensätze der vorherigen Sicherungen, Sicherungspläne und Wiederherstellungen in diesem Repository als lokale benutzerdefinierte Ressourcen in den Zielcluster importiert.
Beim Importieren eines Repositorys als ReadOnly wird das Repository nicht beansprucht. Es werden nur die Sicherungen, Sicherungspläne, Wiederherstellungen und Wiederherstellungspläne importiert. In schreibgeschützten Repositorys werden keine Sicherungen geplant. Sie dienen nur dazu, die in dem Cluster, aus dem Sie importieren, vorhandenen Sicherungspläne sichtbar zu machen. Wenn Sie ein ReadOnly-Repository entfernen, werden alle importierten Ressourcen aus dem Cluster bereinigt. Dies hat keine Auswirkungen auf die Ressourcen am Speicherort, da für schreibgeschützte Repositories keine Schreibvorgänge für den Objektspeicher erfolgen.
Wenn ein ReadWrite-Repository aus dem Cluster entfernt wird, gilt Folgendes:
Alle lokalen benutzerdefinierten Ressourcen, die mit diesem Repository verknüpft sind, z. B. Sicherungen und Wiederherstellungen, werden aus dem aktuellen Cluster entfernt.
Der Anspruch dieses Clusters auf das Repository wird entfernt, sodass das Repository von einem anderen Cluster als ReadWrite verwendet werden kann. Diese Ressourcen werden jedoch nicht vom Speicherendpunkt entfernt.
[[["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-09-04 (UTC)."],[[["\u003cp\u003eThis guide details the process of creating a backup repository in Google Distributed Cloud (GDC) air-gapped environments for storing cluster workload backups and related records.\u003c/p\u003e\n"],["\u003cp\u003eCreating a backup repository requires a compatible endpoint, a pre-existing object storage bucket, granted access to the bucket, and the appropriate identity and access role, like the Organization Backup Admin.\u003c/p\u003e\n"],["\u003cp\u003eRepositories can be created through either the GDC console, involving the input of the main cluster, linked cluster(s), fully qualified domain name, bucket name, region, access key ID and access key; or via API, where a \u003ccode\u003eClusterBackupRepository\u003c/code\u003e custom resource is defined with the relevant credentials and storage details.\u003c/p\u003e\n"],["\u003cp\u003eBackup repositories have two import policies, \u003ccode\u003eReadWrite\u003c/code\u003e for creating new backups and resources, and \u003ccode\u003eReadOnly\u003c/code\u003e for viewing backups without the ability to create new ones, with \u003ccode\u003eReadWrite\u003c/code\u003e repositories being unique to a single cluster, and \u003ccode\u003eReadOnly\u003c/code\u003e available to many.\u003c/p\u003e\n"],["\u003cp\u003eRemoving a \u003ccode\u003eReadWrite\u003c/code\u003e repository from a cluster removes the associated custom resources from the cluster and releases the claim on the repository, while removing a \u003ccode\u003eReadOnly\u003c/code\u003e repository only removes imported resources without affecting the storage location.\u003c/p\u003e\n"]]],[],null,["# Add a backup repository\n\nThis page describes how to create a backup repository for cluster workloads in Google Distributed Cloud (GDC) air-gapped.\n\nA backup repository represents a compatible storage location for your\nbackups. A backup repository is also used to store records of\nbackups, backup plans, restore plans, and restores.\n\nBefore you begin\n----------------\n\nTo create a backup repository, you must have the following:\n\n\u003cbr /\u003e\n\n- A compatible endpoint available.\n- A previously [created bucket](/distributed-cloud/hosted/docs/latest/gdch/platform/pa-user/create-storage-buckets) to use as the backup repository.\n- You have [granted access](/distributed-cloud/hosted/docs/latest/gdch/platform/pa-user/grant-obtain-storage-access) for the object storage bucket.\n- The necessary identity and access role:\n\n - Organization Backup Admin: manages backup resources such as backup and restore plans in user clusters. Ask your Organization IAM Admin to grant you the Organization Backup Admin (`organization-backup-admin`) role. For more information, see [Role\n definitions](/distributed-cloud/hosted/docs/latest/gdch/platform/pa-user/iam/role-definitions).\n\nCreate a repository\n-------------------\n\nCreate a repository by using the GDC console or the API. \n\n### Console\n\n1. Sign in to the GDC console.\n2. In the navigation menu, click **Backup for Clusters**. Ensure no project is selected in the project selector.\n3. Click **Create repository**.\n4. Enter a repository name. The description is optional.\n5. In the **Main cluster (read/write)** list, choose a cluster.\n6. In the **Linked clusters (read only)** list, choose the linked clusters.\n7. In the **S3 URI endpoint** field, enter an endpoint containing the fully-qualified domain name of your object storage site.\n8. In the **Bucket name** field, enter the name of the fully qualified name of the bucket, which can be found from the status of the GDC bucket custom resource.\n9. In the **Bucket region** field, enter the region where the bucket was created.\n10. In the **Access Key ID** list, enter the access key ID.\n11. In the **Access key** field, enter the access key.\n12. Click **Create**.\n\n### API\n\n\nTo use the backup and restore APIs, you must configure a valid\n`ClusterBackupRepository` custom resource to be the location of your\nbackups, and supply the required credentials.\n\n1. Fetch the secret generated in [Grant and obtain storage bucket access](/distributed-cloud/hosted/docs/latest/gdch/platform/pa-user/grant-obtain-storage-access#getting_bucket_access_credentials).\n\n2. Add a `ClusterBackupRepository` custom resource to use these credentials\n and apply the new resource to the Management API server.\n Backup repositories are cluster-scoped:\n\n apiVersion: backup.gdc.goog/v1\n kind: ClusterBackupRepository\n metadata:\n name: user-1-user\n namespace: user-1-user-cluster\n spec:\n secretReference:\n namespace: \"object-storage-secret-ns\"\n name: \"object-storage-secret\"\n endpoint: \"https://objectstorage.google.gdch.test\"\n type: \"S3\"\n s3Options:\n bucket: \"fully-qualified-bucket-name\"\n region: \"us-east-1\"\n forcePathStyle: true\n importPolicy: \"ReadWrite\"\n\n This example includes the following values:\n\nBackup repository import policies\n---------------------------------\n\nAll clusters must have at least one `ReadWrite` repository to successfully use backup and restore features. `ReadOnly` repositories are optional, have no\nlimit, and are used to gain visibility into other cluster backups for\ncross-cluster restores.\n\n`ReadOnly` repositories cannot be used as storage locations for additional\nbackups or for backup plans within the cluster they were imported.\n\nImporting a repository as `ReadWrite` claims the repository for that cluster,\npreventing other clusters from importing the same repository as\n`ReadWrite`. After importing a `ReadWrite` repository, all records of previous\nbackups, backup plans, and restores in that repository are imported into the\ntarget cluster as local custom resources.\n\nImporting a repository as `ReadOnly` does not claim the repository, it only\nimports the backups, backup plans, restores, and restore plans. Backup plans in read-only repositories don't schedule backups,\nthey exist to provide visibility into what backup plans exist in the cluster you are importing from. Removing a `ReadOnly` repository cleans up any imported resources from\nthe cluster and has no effect on the resources in the storage location as no write operations occur to object storage for read-only repositories.\n\nWhen a `ReadWrite` repository is removed from the cluster:\n\n- All local custom resources associated with that repository, such as backups and restores, are removed from the current cluster.\n- That cluster's claim on the repository is removed, allowing the repository to be used as `ReadWrite` by another cluster. However, these resources are not removed from the storage endpoint.\n\nWhat's next\n-----------\n\n- [Customize backup and restore for an application](/distributed-cloud/hosted/docs/latest/gdch/platform-application/pa-ao-operations/cluster-backup/customize-backup-restore)\n- [Plan a set of backups](/distributed-cloud/hosted/docs/latest/gdch/platform-application/pa-ao-operations/cluster-backup/plan-backups)"]]
