此内容没有您所选择的语言版本。

Chapter 4. Troubleshooting data backup and restore


To troubleshoot failed data backups and restorations, check the basics first, such as data paths, storage configuration, and storage capacity.

4.1. Backing up data failed

Data backups are automatic on rpm-ostree systems. If you are not using an rpm-ostree system and attempted to create a manual backup, the following reasons can cause the backup to fail:

  • Not waiting several minutes after a system start to successfully stop MicroShift. The system must complete health checks and any other background processes before a back up can succeed.
  • If MicroShift stopped running because of an error, you cannot perform a backup of the data.

    • Make sure the system is healthy.
    • Stop it in a healthy state before attempting a backup.
  • If you do not have sufficient storage for the data, the backup fails. Ensure that you have enough storage for the MicroShift data.
  • If you do not have sufficient permissions, a backup can fail. Ensure you have the correct user permissions to create a backup and perform the required configurations.

4.2. Backup logs

  • Logs print to the terminal console during manual backups.
  • Logs are automatically generated for rpm-ostree system automated backups as part of the MicroShift journal logs. You can check the logs by running the following command:

    $ sudo journalctl -u microshift
    Copy to Clipboard Toggle word wrap

4.3. Restoring data failed

The restoration of data can fail for many reasons, including storage and permission issues. Mismatched data versions can cause failures when MicroShift restarts.

4.3.1. RPM-OSTree-based systems data restore failed

Data restorations are automatic on rpm-ostree systems, but can fail, for example:

  • The only backups that are restored on rpm-ostree systems are backups from the current deployment or a rollback deployment. Backups are not taken on an unhealthy system.

    • Only the latest backups that have corresponding deployments are retained. Outdated backups that do not have a matching deployment are automatically removed.
    • Data is usually not restored from a newer version of MicroShift.
    • Ensure that the data you are restoring follows same versioning pattern as the update path. For example, if the destination version of MicroShift is an older version than the version of the MicroShift data you are currently using, the restoration can fail.

4.3.2. RPM-based manual data restore failed

If you are using an RPM system that is not rpm-ostree and tried to restore a manual backup, the following reasons can cause the restoration to fail:

  • If MicroShift stopped running because of an error, you cannot restore data.

    • Make sure the system is healthy.
    • Start it in a healthy state before attempting to restore data.
  • If you do not have enough storage space allocated for the incoming data, the restoration fails.

    • Make sure that your current system storage is configured to accept the restored data.
  • You are attempting to restore data from a newer version of MicroShift.

    • Ensure that the data you are restoring follows same versioning pattern as the update path. For example, if the destination version of MicroShift is an older version than the version of the MicroShift data you are attempting to use, the restoration can fail.

4.4. Storage migration failed

Storage migration failures are typically caused by substantial changes in custom resources (CRs) from one MicroShift to the next. If a storage migration fails, there is usually an unresolvable discrepancy between versions that requires manual review.

返回顶部
Red Hat logoGithubredditYoutubeTwitter

学习

尝试、购买和销售

社区

关于红帽文档

通过我们的产品和服务,以及可以信赖的内容,帮助红帽用户创新并实现他们的目标。 了解我们当前的更新.

让开源更具包容性

红帽致力于替换我们的代码、文档和 Web 属性中存在问题的语言。欲了解更多详情,请参阅红帽博客.

關於紅帽

我们提供强化的解决方案,使企业能够更轻松地跨平台和环境(从核心数据中心到网络边缘)工作。

Theme

© 2025 Red Hat