-
Notifications
You must be signed in to change notification settings - Fork 34
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Automatic upgrade process - Disable Backup #145
Comments
@Nono-m0le Do you have any logs regarding the backup step that can't be done? |
504 error from the front end.
…----- Message de réponse -----
De : "Morris Jobke" <[email protected]>
Pour : "nextcloud/updater" <[email protected]>
Cc : "Nono" <[email protected]>, "Mention" <[email protected]>
Objet : [nextcloud/updater] Automatic upgrade process - Disable Backup (#145)
Date : lun., sept. 25, 2017 13:41
@Nono-m0le Do you have any logs regarding the backup step that can't be done?
—You are receiving this because you were mentioned.Reply to this email directly, view it on GitHub, or mute the thread.
|
Could you post your updater.log from the data dir? |
Here it is. It must shown 1 or 2 tries from the automatic updater and I finish by using the updater.phar : 2017-09-25T11:32:58+0200 q9HCcAUB4H [info] request to updater 2017-09-25T11:32:59+0200 q9HCcAUB4H [info] checkForUpdate() Array 2017-09-25T11:32:59+0200 q9HCcAUB4H [info] end of checkForUpdate() Update to Nextcloud 11.0.5 available. (channel: "stable") 2017-09-25T10:24:59+0000 2nPp6rji2H [info] checkForUpdate() Array 2017-09-25T10:24:59+0000 2nPp6rji2H [info] end of checkForUpdate() Update to Nextcloud 11.0.5 available. (channel: "stable") 2017-09-25T10:25:05+0000 2nPp6rji2H [info] storage location exists |
I would say, that your webserver killed the pending request. Nothing we can do here. If the web server decides do kill it after a given time, it is killed (the request not the PHP process as you can see, that the process finished fine after 8,5 minutes). This can basically happen in all tasks. So disabling that one would not help at all. Use the CLI based updater and this is not really a problem. Sorry - we can't do much here. |
How can I disable (manually) this step to check if the upgrade still fail without?! |
The backup does a copy of the existing code to be able to rollback if something went wrong later. Another way: maybe have a look why taking a backup of some thousand files with a total amount of 50 MB takes 8,5 minutes. Maybe there is an I/O limit hit. |
could be, but still won't let me disable this step ... |
I really don't like to allow people to randomly disable stuff, that we put in place for a reason. If the web updater doesn't work for you we can not do much and disabling stuff, just because "if we disable it it works" is not a good approach. There is a reason why it doesn't work. And at some day it will fail in the "copy code over" step and then the problem is bigger. So better don't use it then and rely on the updater.phar, which works a lot better and don't has this timeout problem. |
and I understand your approach (which btw seems to be the good one). |
because it then would have the same problem. The CLI and the web is exactly the same code, but for the web we run through the web server, which could kill the process. The CLI is not piped through a webserver and therefore can not be killed by it. If you now propose to run the CLI via the webserver it would eliminate the advantages and make it not better. |
So, I don't want to start a new discussion, but I only want to mention, thet I have a huge amount of files in the data section. These files are backed up by other services, so I don't need to backup them twice. I also have to wait for the backup approx three days to finish?? I think thats not practible. Maybe you can put a config param or something like that to disable the backup procedure? |
The backup only backs up the code and not the data directory. It could be a bit slower because it copies a lot of small files, which could cause some performance issues depending on the filesystem you are writing them to. |
OK, I understand. Thank you. |
There might be the case where you can't change your PHP settings eg if you use shared hosting. In this case, you can do an update by hand and then disabling the backup function in the updater by going to your nextcloud main directory and then to the updater/index.php and comment out line 1291 |
I actually tried that during the last upgrade and it didn't work ... |
The update works with the phar file (compressed file). If you want modify it, you must extract the phar file in the updater directory and use update.php. |
in NC 15 I commented the code at row 356 into file
and after I use the |
finally ... it really drives me nuts that everytime I want to upgrad NC I need to try 1000 times (it is literally usually more than 10) until finally with lots of luck it works. Most remarkable is that this problem is not seen as a problem by the programmers and there are lots of threads each time NC receives an upgrade. |
Now I try the update to 16.0.5 ... and wich step doesn't work for me? |
something is wrong with your server settings. Probably something beyond your control. Some timeout or CPU capacity that you just did not pay enough to get it extended ... and that is the reason why this point is not seen as a problem by NC programmers: if you had total control of your server you would never run into that issue ... |
For skipping the backup in 16.0.3, what worked for me was was commenting out lines 1332-4 of /updater/index.php which reads when commented out: |
@drwwww commenting out the lines in 17.0.2 to disable the backup doesn't work any more |
I succeeded in updating 17.0.3 to 18.0.3 by commenting out lines 1335-7 of nextcloud/updater/index.php as follows:
|
Just in case anyone else has the same issue, I also found that during Step 4, the download timed out. I got an error "Step 4 is currently in process. Please reload this page later". I fixed it by:
|
Just to reference the development: You can disable the backup in CLI mode with |
That's brilliant, thanks! |
The Updater bails with 'Backup failed' the moment it is unable top copy a single file (eg. a config.php~ because someone edited this file as root). IMHO: |
Would that be possible to be able to choose whenever we want to do a backup during a automatic upgrade ?
On my case, I'm taking care of the backup on the server side (cli) and I can't use the automatic upgrade process because the "Create backup" task systematically failed for various reasons:
The first reason is the nginx in front-end and the apache2 on the back-end which is hosting my instance.
Another reason is the utilization of ldap as nextcloud & system authentification (www-data not the same on the front / back-end / NFS Server)
Finally, the server host their file on an NFS server (not locally) which is also had a complexity in term of user rights.
I agree all those points are basically my issue / wrong configuration but the automatic update shouldn't be unuable (at all) because of a "backup step" I don't really need/use.
The text was updated successfully, but these errors were encountered: