Exactly! I do this with clients already. The problem is how to save them in the event of a server failure. I already have methods in place to make frequent backups of the databases and supporting files.
The problem is being able to replace the installed program with the exact same version the users were running before the failure. THIS is where I find the difficulty.
The only successful approach I have found is to have a complete image backup that I can have restored to a brand new server when there is a failure. This is because there is actually no effective way to re-install ERPNext to a point version that the users were on before the failure event.
Someone here suggested making a tarball from the frappe-bench bench directory and unzipping it to a new server then restoring the database and the support files. However, when I tried this in the past I could not get the server to work. Important pieces are not residing in the frapp-bench directory like the mariadb programs, and nginx, etc. Hopefully someone that has been successful with the tarball approach can elaborate a little on how to get it working.
However, up to this point I have not heard of anyone that can for example install a v10.0.14 version of ERPNExt on a fresh server and then restore their backups. For that matter it is not reliable to try to install the last supported version of v10 and expect that it will be identical to the same installation a week later due to the constant changes happening in all of the supporting packages.
This is why I compared it to NOT being like a MS Windows package. I have installed many MS Windows Server 2016 packages where everything is built into the cab files that are used to do the install. Doing it this way gives you the exact same install every time not matter if it is this week, next week, or next year, the server will just work! So no I am not comparing some simple desktop install to a server install.
Exactly again!!
I take it a step further and freeze the production server at whatever point revision it is when it goes live and I do NOT allow any updates for 2 to 3 years. I provide a live production server, a āsandboxā server for users to practice how they use the system, and 1 or 2 hot spare servers that are automatically updated every hour with fresh database and support file backups.
In this case I do not need a ābetaā server because I do not allow upgrades anyway. All I care about is being able to replace any one of the servers with a fresh one in the event there is a hardware failure at the server farm. THIS is all I am referring to when I decry the inability to make a fresh copy of an older server (even if it is supposedly still a supported version).
Currently I have one configuration where the primary live production server is in New York. The same day I created it, I also took an image backup of it and restored it to identical servers in New Jersey, Chicago, and Los Angeles. This gave me a production server and 3 possible hot spare backups. One day last year the primary live production server in New York failed and all information was lost and unrecoverable. No problem, I just switched the users to the New Jersey server and kept on going.
The problem came around when I tried to replace the bad New York server with another one configured exactly the same way. Since the time I created the original servers the VPS service provider changed their standard configuration to include a little more memory and a little less disk space but moved to SSD drives. Now my image backup will not restore to the servers of the new configuration due to the disk size differences and I have no way to get back a replacement server for the dead one. The great techs at the service provider tried everything they could think of and could not get a restore process to work.
Now the question is how do I re-create another server with the exact same version of the software? So far, I cannot. This is the problem I have been search an answer for and not whatever everyone else has been reading into my posts.
I am happy that you find value in the constant updates to ERPNext. Your experience is exactly the opposite of mine in this respect. I have not found a single user base that was comfortable with interrupting their users to teach them new ways they might have to use their software each time it changes. Changes to them cause work slow downs and impede their revenue flow. This is why they all choose to have wither 2 year freezes or 3 year freezes on version changes when they sign with me. Almost all of them have had the terrible experience of upgrading versions frequently of other software and specifically want a guarantee that they will be protected from that situation for a fixed period of time.
BKM