Chapter 1. Overview
In the event of a hardware issue or some other serious problem, you may need to replace a failed host.
Minimize restore time by backing up disk configuration: Chapter 2, Backing up important files. This is not required to restore brick contents, but it does make the process faster.
The process differs depending on the following factors:
- Is data on the disks intact?
- Have you backed up or can you safely back up host configuration details?
- Is the failed host a primary volfile server (the server whose FQDN is used to mount gluster volumes, usually the first host in the cluster)?
Follow the process that best fits your situation:
If your disks are intact, you can reinstall the same host and use the same FQDN regardless of whether the server is the primary volfile server.
- If you can back up configuration details, follow Chapter 3, Reusing bricks and restoring configuration from backups.
- If you cannot back up configuration details, follow Chapter 4, Reusing bricks and reconstructing existing brick configuration.
If your disks are not intact or you want the replacement host to use a different FQDN:
If the host that failed was the primary volfile server, use Chapter 6, Replacing a primary host using new bricks.
ImportantThis process requires that virtual machines are taken offline.
- If the host that failed was not the primary volfile server, use Chapter 7, Replacing a non-primary host using new bricks.