You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: content/admin/managing-github-actions-for-your-enterprise/advanced-configuration-and-troubleshooting/migrating-github-actions-external-storage.md
+22-22Lines changed: 22 additions & 22 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -10,11 +10,11 @@ category:
10
10
- Enable GitHub features for your enterprise
11
11
---
12
12
13
-
## About migrating {% data variables.product.prodname_actions %} external storage
14
-
15
-
You can migrate {% data variables.product.prodname_actions %} external storage to a new bucket, account, or region on the same provider when consolidating cloud accounts, meeting residency requirements, or reorganizing storage tenancy.
16
-
17
-
The migration works because {% data variables.product.prodname_actions %} identifies stored objects by their key (path) within a bucket or container, not by the bucket or account name. As long as you preserve the internal key layout and update your configuration to point at the new location, existing workflow logs and artifacts remain accessible without interruption.
13
+
## About migrating {% data variables.product.prodname_actions %} external storage
14
+
15
+
You can migrate {% data variables.product.prodname_actions %} external storage to a new bucket, account, or region on the same provider when consolidating cloud accounts, meeting residency requirements, or reorganizing storage tenancy.
16
+
17
+
The migration works because {% data variables.product.prodname_actions %} identifies stored objects by their key (path) within a bucket or container, not by the bucket or account name. As long as you preserve the internal key layout and update your configuration to point at the new location, existing workflow logs and artifacts remain accessible without interruption.
18
18
19
19
## Considerations
20
20
@@ -43,12 +43,12 @@ Before you begin, review the following constraints. Each one shapes the migratio
43
43
44
44
Before performing the migration against production, rehearse the full procedure on a staging instance. Provision a staging {% data variables.product.prodname_ghe_server %} instance from a recent production backup, point it at a throwaway destination that mirrors the intended production destination, and run every step of this article end to end. For more information, see [AUTOTITLE](/admin/installation/setting-up-a-github-enterprise-server-instance/setting-up-a-staging-instance) and [AUTOTITLE](/admin/managing-github-actions-for-your-enterprise/advanced-configuration-and-troubleshooting/using-a-staging-environment).
45
45
46
-
A staging rehearsal validates that:
47
-
48
-
* Provider-side permissions, network access, and policies on the destination are correct.
49
-
* The copy tool you have chosen completes successfully against representative data volumes.
50
-
* The expected object count and total size match between source and destination.
51
-
* Existing workflow run logs and artifacts are retrievable through the UI after cutover.
46
+
A staging rehearsal validates that:
47
+
48
+
* Provider-side permissions, network access, and policies on the destination are correct.
49
+
* The copy tool you have chosen completes successfully against representative data volumes.
50
+
* The expected object count and total size match between source and destination.
51
+
* Existing workflow run logs and artifacts are retrievable through the UI after cutover.
52
52
53
53
> [!WARNING]
54
54
> Your staging instance must use different storage from your production instance. If you do not change the storage configuration, the staging instance may write into your production storage and cause data loss. For more information, see [AUTOTITLE](/admin/managing-github-actions-for-your-enterprise/advanced-configuration-and-troubleshooting/using-a-staging-environment#configuring-storage).
@@ -135,23 +135,23 @@ Work through the following steps in order. {% data variables.product.prodname_ac
135
135
136
136
If validation fails or you encounter issues after cutover, roll back by pointing {% data variables.location.product_location %} back at the source storage location. The source storage is your known-good copy. Do not copy data from the destination back into the source as part of rollback, because data written to the destination during a failed cutover may be partial or inconsistent, and writing it back into the source risks corrupting your only good copy.
137
137
138
-
> [!WARNING]
139
-
> Rolling back will discard any data written or deleted after the cutover. If validation fails, roll back immediately rather than attempting extended troubleshooting. The longer you wait, the more data is at risk.
140
-
141
-
If validation fails or you encounter issues:
142
-
143
-
1. Enable maintenance mode immediately.
144
-
1. In the {% data variables.enterprise.management_console %}, restore the original storage configuration values and click **Test storage settings**, then **Save settings**.
145
-
1. Disable maintenance mode and re-run the validation steps with the original storage.
146
-
147
-
After a successful rollback, investigate the failure and plan a new migration attempt.
138
+
> [!WARNING]
139
+
> Rolling back will discard any data written or deleted after the cutover. If validation fails, roll back immediately rather than attempting extended troubleshooting. The longer you wait, the more data is at risk.
140
+
141
+
If validation fails or you encounter issues:
142
+
143
+
1. Enable maintenance mode immediately.
144
+
1. In the {% data variables.enterprise.management_console %}, restore the original storage configuration values and click **Test storage settings**, then **Save settings**.
145
+
1. Disable maintenance mode and re-run the validation steps with the original storage.
146
+
147
+
After a successful rollback, investigate the failure and plan a new migration attempt.
148
148
149
149
## {% data variables.product.prodname_registry %} considerations
150
150
151
151
You can apply the same migration approach to {% data variables.product.prodname_registry %} external storage, with the following important differences. Read this section in full before migrating storage on an instance that has {% data variables.product.prodname_registry %} enabled.
152
152
153
153
***OpenID Connect is not available for {% data variables.product.prodname_registry %}.** {% data variables.product.prodname_registry %} only supports credentials-based authentication for external storage. The authentication-method constraint in this article still applies: keep the authentication method unchanged during migration.
154
-
***{% data variables.product.prodname_registry %} is more sensitive to timing mismatches.** When packages are published during the migration window, the system creates both new storage objects and database records. To prevent inconsistency, keep maintenance mode enabled continuously from the start of the final delta sync through successful validation of the new configuration.
154
+
***{% data variables.product.prodname_registry %} is more sensitive to timing mismatches.** When packages are published during the migration window, the system creates both new storage objects and database records. To prevent inconsistency, keep maintenance mode enabled continuously from the start of the final delta sync through successful validation of the new configuration.
155
155
***Update both configurations together if the same provider serves both products.** If you have configured {% data variables.product.prodname_actions %} and {% data variables.product.prodname_registry %} to use the same provider type and you are migrating both, plan the cutover as a single maintenance window and update both configurations before disabling maintenance mode.
156
156
***For cross-provider migrations of {% data variables.product.prodname_registry %} storage, contact {% data variables.contact.contact_ent_support %}.** Cross-provider moves are not covered here.
0 commit comments