Current Behavior: The current restore process in mgob is limited to archives located in the /storage directory. This setup requires users to manually download backup archives from configured remotes (such as S3) into the local /storage directory for mgob to recognize and initiate the restore process.
Problem: This manual intervention is highly inconvenient and time-consuming, especially during disaster recovery scenarios where timely restoration of databases is critical. In such situations, users often need to access the most recent backup archive stored on a remote location, and the need to first download it locally adds an unnecessary layer of complexity and delay.
Proposed Enhancement:
Local Directory Check: By default, the restore process should first check for the presence of the required archive in the local /storage directory.
Remote Check: If the archive is not found locally, mgob should automatically check the configured remote location (e.g., S3) and fetch the necessary archive to proceed with the restore process.
Benefits:
Efficiency: Streamlines the restore process by eliminating the need for manual intervention to download backup archives from remote locations.
Speed: Reduces downtime during disaster recovery by enabling a more automated and seamless restore process.
User Experience: Improves overall user experience by providing a more robust and reliable restore mechanism.
Implementation Suggestions:
Extend the existing restore functionality to include a check for remote storage if the archive is not found locally.
Implement configurable options to specify the remote location credentials and access details.
Ensure proper logging and error handling to inform users of the restore process and any issues encountered while fetching the archive from the remote location.
It is a good idea. Currently I have my own script to do the recovery thing from S3, but it will be nice to have this feature for sure. Welcome to make a PR!
Current Behavior: The current restore process in mgob is limited to archives located in the /storage directory. This setup requires users to manually download backup archives from configured remotes (such as S3) into the local /storage directory for mgob to recognize and initiate the restore process.
Problem: This manual intervention is highly inconvenient and time-consuming, especially during disaster recovery scenarios where timely restoration of databases is critical. In such situations, users often need to access the most recent backup archive stored on a remote location, and the need to first download it locally adds an unnecessary layer of complexity and delay.
Proposed Enhancement:
Local Directory Check: By default, the restore process should first check for the presence of the required archive in the local /storage directory.
Remote Check: If the archive is not found locally, mgob should automatically check the configured remote location (e.g., S3) and fetch the necessary archive to proceed with the restore process.
Benefits:
Efficiency: Streamlines the restore process by eliminating the need for manual intervention to download backup archives from remote locations.
Speed: Reduces downtime during disaster recovery by enabling a more automated and seamless restore process.
User Experience: Improves overall user experience by providing a more robust and reliable restore mechanism.
Implementation Suggestions:
Extend the existing restore functionality to include a check for remote storage if the archive is not found locally.
Implement configurable options to specify the remote location credentials and access details.
Ensure proper logging and error handling to inform users of the restore process and any issues encountered while fetching the archive from the remote location.