[Feature]: Ability to run the upgrader outside of the data directory #58190
Description
Tip
Help move this idea forward
- Use the 👍 reaction to show support for this feature.
- Avoid commenting unless you have relevant information to add; unnecessary comments create noise for subscribers.
- Subscribe to receive notifications about status changes and new comments.
Is your feature request related to a problem? Please describe.
Hello, I have done a quick search on the issues and couldn't find this topic. I also did some internet searches but I didn't fully understand if the scope was the same.
I am experiencing a performance issue during Nextcloud software upgrade due to a unique and peculiar setup that I have.
Since I want to run a personal instance of Nextcloud in economy mode in a VPS that runs LAMP stack, I chose to store datadirectory directory under an Azure Blob storage mounted via NFS on my VPS, and in this particular case my blob storage is set for cold storage. This storage is particularly slower than the hot one (and not as slow as the archive tier, which may answer in hours)
This setup was designed since I run a personal instance and don't require quick and prompt access to my shared files (e.g. I can wait few seconds for them to be served).
During Nextcloud upgrade, the auto-upgrade will backup and extract files under the datadirectory directory. I didn't know about this when I first designed my setup (first times happen for everyone), so I ended up an an endless backup step.
UPDATE: the archive extraction phase is affected along with the backup. Disabling backup won't have any effect
Describe the solution you'd like
As a professional, I would suggest my own approach.
The most aggressive solution, from the architectural point of view, could be segregating datadirectory into at least two directories, one that stores data of the users (and a savy administrator may put under backup, dedicated storage, gdpr compliance, etc.), and another workingdirectory that may serve as the root directory of all files that are not data and shall not be in the publicly-facing htdocs folder of the application.
Less aggressively, one would think of configuring a dedicated workingdirectory for the updater only, in my case it would be mapped to a staging directory under VPS main small SSD disk
Describe alternatives you've considered
In my unique setup, I am having a hard time finding an alternate. I would have to move a to a containerized environment (namely AKS) so that I upgrade the image only and voilà. But that impacts with the costs I am available to sustain for such an amateur project.
Additional context
Of course, this is an idea for an improvement. Maintainers can easily find inspiration for continuous improvement or consider this one is a unique case of a single user that is not affecting any business (being personal project).
So I will thank you for your attention and be available for further clarification.