Ok, I’m back to update/correct my findings, and give the test cases. My previous post indicated that a recreated user could not access a restored Business file - I proved that to be FALSE (setting the record straight) and proved to myself that the system is pretty resilient as well, and easy to backup and restore.
First, the setup is: self-hosted server, 2 Business files, 1 extra admin user, and 1 restricted user (restricted to 1 Business with just Project and Purchase perms). Backups of both Businesses were done through the web interface at this point. I also made a copy of all the files (4) in the Local/Manager folder at this time (2 .Manager files, 0000… and password).
For the first 3 tests (there are 5), the Businesses were removed through the web interface first, then both the extra users. Then Businesses were restored (various ways), and users recreated (in that order).
There are 3 ways to “restore” a Business file, and 1 way to restore Users - that’s what I tested.
Test 1 - after the above setup, Businesses were deleted, then extra users. To restore, the .Manager files were simply moved back out of the Manager/Trash folder into the Manager folder. Admin logged in, could see both Businesses, verified User Permissions for the restricted user were still present, and after recreating the extra users (as defined above), the restricted user could log in, restricted to just the permissions give. Worked as expected, no setbacks.
Test 2 - after the above setup, Businesses were deleted, then extra users. To restore, the Businesses were imported back into the system through the Add Business function, leaving the dates in the Business names (which come from the name of the backup files). Admin logged in, could see both Businesses, verified User Permissions for the restricted user were still present, and after recreating the extra users (as defined above), the restricted user could log in, restricted to just the permissions give. Worked as expected, no setbacks, however the Business names included a date in them.
Test 3 - was done the same as Test 2, but the backup files were renamed to remove the date from the filename before restoration. The results were identical, but the Business names were now cleaner, with no date in the Business name (this was the preferred result).
Test 4 - This simulated a catastrophic failure. I stopped the ManagerServer service, deleted all the files in Manager/Local folder, then copied in the manual copies I had made in the initial setup, and restarted the ManagerServer service. Worked as expected, no setbacks, all users and Businesses present.
Test 5 - This was just to test file corruption. After Test 4, without stopping the ManagerServer service, I deleted the 000… file. Attempts to log in with any user yielded SQLite server errors. The 0000… file had been recreated by the server. Restarting the ManagerServer service allowed the Admin to log back in, and both Businesses were there, but no extra users were present. I stopped the ManagerServer service again, copied in the manually backed up 0000… file from my backups, and started ManagerServer. Worked as expected, no setbacks, all users and Businesses present.
So, in summary, it seems 99% bulletproof as far as Business backups and manually copying the Local/Manager folder goes. I’m assuming the backups through the web interface are really just copying the .Manager files directly without any compression or conversion (like an SQL dump), so really, just copying the Local/Manager folder is the best backup. Easy to restore just users or just a business by moving files around. For users without direct access to the server, the Import and recreating users is the way to go.
A note on recreating users - the only part of the recreated user that needs to be identical is the Username - the Name and Password fields can be different (each time I recreated the restricted user, those were unique). The Business file appears to ONLY link to the user by the Username field. Not sure this is the most secure way to do this, as there is a scenario where one person could remove a user, then someone else could recreate that user, and if permissions weren’t removed when the user was, or weren’t set to None, then that recreated username would again have access to the Business. For recovery purposes this is convenient, but it would be better if there was a unique key involved, and when the username was recreated, there would be a check to see if relinking them to the company file was desired or not, then update the key assigned to the username in the Business file if desired.
My thoughts and findings - thanks.