NEW UPDATE pulls other app backup...WHAT is going ON?

[nebulon]

Are you seeing an issue after a Cloudron update or an update to a (presumably WordPress) app instance?

Also are those both WordPress app instances?

Can you trigger a manual backup on the app? Also how did you find out that the backup was made from another app or so?

[johnbolt]

@nebulon said in NEW UPDATE pulls other app backup...WHAT the CRAP is going ON?:

WordPress app instanc

I tried to restore from the Wordpress app instance backup in storage. I can trigger a manual backup but it restores wrong backup because the app is from other app instance. Both are Wordpress instances. I cannot tell you whether the issue was caused by Wordpress update or Cloudron update. It looks like only one of my apps are affected. I am going through all instances to see.

[nebulon]

Did you clone one of those app instance from another at some point in the past? Generally app instances, even of the same package, are handled entirely independently, so I am wondering how those backups can be mixed up.

[johnbolt]

@nebulon said in NEW UPDATE pulls other app backup...WHAT the CRAP is going ON?:

ng how those backups can be mixed up.

Nope. I am totally at a lost. Anybody know how to get me a reputation point? (Will respond in 6 minutes)

[johnbolt]

Looks like it affected one of my non Cloudron controlled worpress sites.

[johnbolt]

btw sorry for negative wording. Am a developer so I know things happen. I will try to research deeper into this on my end.

[johnbolt]

is there anyway to manually download the backup and inspect it individually?

[BrutalBirdie]

@johnbolt Sorry John but with the lack of information about your system I am not willing to invest any time.

To your last question, of course you can download your backups, but since you did not give any information about your setup, all I can do is - RTFM.

https://docs.cloudron.io/backups/

@johnbolt said in NEW UPDATE pulls other app backup...WHAT the CRAP is going ON?:

Looks like it affected one of my non Cloudron controlled worpress sites.

What? A Wordpress site is affected which is not even controlled by Cloudron? o_O wtf?

Every app has it's own id which also is used for the backups.
Example one of my lamp apps has the id 07458679-64b6-4921-9f37-318a57518f85
and the backup name is:
app_435994c4-bb05-43a6-b941-9f9440fe5124_2020-09-22-210133-071_v1.4.0.tar.gz

[nebulon]

Indeed we need a lot more information to give any helpful ideas or insights to your situation. Maybe you can start by describing your setup and how many apps are involved, when they were updated and so forth...

[johnbolt]

This post is deleted!

[nebulon]

Hm I think to get to the bottom of this we need direct access to your server to take a look at what is happening with the backups. If you want, you can enable remote ssh for your server and then send us a mail to support@cloudron.io with the dashboard domain.

[girish]

The issue had to do with yoast plugin erroring:

[Wed Sep 23 23:31:36.122693 2020] [php7:error] [pid 92] [client 172.18.0.1:47894] PHP Fatal error:  Namespace declaration statement has to be the very first statement or 
after any declare call in the script in /app/data/wp-content/plugins/wordpress-seo/src/presenters/webmaster/google-presenter.php on line 8, referer: ...

It seems this error has been reported already: https://wordpress.org/support/topic/yoast-seo-plugin-crashed/ and https://wordpress.org/support/topic/yoast-premium-fatal-error/ but there are no real solution other than updating the plugin.

So, I put the app in repair mode. Went to the terminal and ran:

/app/pkg/wp --allow-root --skip-plugins plugin deactivate wordpress-seo

Then, I disabled repair mode and the app came back up. Then, I went to the admin dashboard and updated the plugin and activated it. That seemed to fix it.

[johnbolt]

Is there a reason for another one of my applications showing up when I put in repair mode?

[girish]

@johnbolt I have a hunch on why this might be happening, let me confirm and get back. Rest assured, it's not to do with backups or the restore but something to do with our nginx configs.

[girish]

OK, that wasn't the issue. We have an issue with the Cloudron 5.6.1 release that http://ip will serve up a random app. This is because we ended up removing 'default_server' and the nginx behavior is to serve up the first server it finds. Not the end of the world, but not nice. This issue has been fixed now.

I thought the above was the reason you were getting served up some other app when you put an app in repair mode. I tested it now, but this is not the case. If you can duplicate this and let me know, I would like to have a look.