mirror of
https://github.com/openshift/openshift-docs.git
synced 2026-02-05 12:46:18 +01:00
44 lines
1.9 KiB
Plaintext
44 lines
1.9 KiB
Plaintext
// Module included in the following assemblies:
|
|
//
|
|
// * migrating_from_ocp_3_to_4/troubleshooting-3-4.adoc
|
|
// * migration_toolkit_for_containers/troubleshooting-mtc
|
|
|
|
:_mod-docs-content-type: PROCEDURE
|
|
[id="migration-rolling-back-migration-web-console_{context}"]
|
|
= Rolling back a migration by using the {mtc-short} web console
|
|
|
|
You can roll back a migration by using the {mtc-first} web console.
|
|
|
|
[NOTE]
|
|
====
|
|
The following resources remain in the migrated namespaces for debugging after a failed direct volume migration (DVM):
|
|
|
|
* Config maps (source and destination clusters)
|
|
* `Secret` objects (source and destination clusters)
|
|
* `Rsync` CRs (source cluster)
|
|
|
|
These resources do not affect rollback. You can delete them manually.
|
|
|
|
If you later run the same migration plan successfully, the resources from the failed migration are deleted automatically.
|
|
====
|
|
|
|
If your application was stopped during a failed migration, you must roll back the migration to prevent data corruption in the persistent volume.
|
|
|
|
Rollback is not required if the application was not stopped during migration because the original application is still running on the source cluster.
|
|
|
|
.Procedure
|
|
|
|
. In the {mtc-short} web console, click *Migration plans*.
|
|
. Click the Options menu {kebab} beside a migration plan and select *Rollback* under *Migration*.
|
|
. Click *Rollback* and wait for rollback to complete.
|
|
+
|
|
In the migration plan details, *Rollback succeeded* is displayed.
|
|
|
|
. Verify that rollback was successful in the {product-title} web console of the source cluster:
|
|
|
|
.. Click *Home* -> *Projects*.
|
|
.. Click the migrated project to view its status.
|
|
.. In the *Routes* section, click *Location* to verify that the application is functioning, if applicable.
|
|
.. Click *Workloads* -> *Pods* to verify that the pods are running in the migrated namespace.
|
|
.. Click *Storage* -> *Persistent volumes* to verify that the migrated persistent volume is correctly provisioned.
|