Hello @aftechro, welcome back, and great job on the Backup/Restore feature. The UI you've developed is impressive.
Nevertheless, as @wrongecho pointed out, there are additional aspects to consider in the backup/restore process. A specific issue arises when backing up the database and then deleting an entity such as a contact, user, or any item with associated files. If a restore is performed, the previously deleted user's folder remains in /uploads/users/ID/Files. This could lead to complications, such as a new user being assigned the ID of a deleted user.
A potential solution could be to include the entire ITFlow directory in the backup, along with the database schema. The backup could be in the form of a compressed tar file, named something like 2024-01-04-13-10-10-ITFlow-Backup.tar.gz.
Ideally, this backup process should be automated through a daily Cron job using a PHP script. Relying on the UI for backups could lead to prolonged loading times or timeouts, depending on the size of the files and database. This feature could be an optional setting.
Furthermore, it might be beneficial to dedicate a separate SQL table for backups, which would track details like database version, GIT commit hash, and include hash verification of the tar.gz file for consistency checks during restoration.
This project is quite expansive, encompassing more variables than just those discussed by @wrongecho and myself.
We'll likely need to consider this for version 2.0, as we are currently focused on resolving existing bugs.
The concept and direction are promising, and we've already received positive user feedback. However, for the time being, we still recommend backing up the entire Virtual Machine now.
