Quantcast
Channel: Backup and restore
Viewing all articles
Browse latest Browse all 6815

Re: Restore fails silently without errors

$
0
0
by Remco Aalderink.  

Unfortunately our Moodle instance is absolutely massive, so the health tool times out. I'm talking 33 million questions in the database. Dissecting what the health tool does, the query to check for orphaned multianswer questions is what takes forever (we use a lot of those), and doesn't even finish within an hour, even after optimizing that query a little bit. However, I'm quite sure that there are orphans, but uncertain if that is the issue here.

We have all forms of debug on, so our backup log files aren't 0 byte, but it only shows status changes. For example:
 
[Mon Jul  8 10:53:22 2024] [info] instantiating restore controller c1b1c15d42023e172b3f59ec45a11974
[Mon Jul  8 10:53:22 2024] [debug] setting controller status to 100
[Mon Jul  8 10:53:22 2024] [debug] loading backup info
[Mon Jul  8 10:53:22 2024] [debug] loading controller plan
[Mon Jul  8 10:53:22 2024] [debug] setting controller status to 300
[Mon Jul  8 10:53:22 2024] [debug] applying restore defaults
[Mon Jul  8 10:53:22 2024] [debug] Unknown setting: questionbank
[Mon Jul  8 10:53:22 2024] [debug] setting controller status to 400
[Mon Jul  8 10:53:22 2024] [info] checking plan security
[Mon Jul  8 10:53:22 2024] [debug] setting controller status to 600
[Mon Jul  8 10:53:22 2024] [debug] saving controller to db
[Mon Jul  8 10:53:22 2024] [debug] calculating controller checksum a0da7b1f7c7b9b4d5eaa5abe8b989a07
[Mon Jul  8 10:53:22 2024] [debug] loading controller from db
[Mon Jul  8 10:58:21 2024] [debug] setting controller status to 700
[Mon Jul  8 10:58:21 2024] [debug] saving controller to db
[Mon Jul  8 10:58:21 2024] [debug] calculating controller checksum 97e7ef6d77b97ec5fc02d67e26976d25
[Mon Jul  8 10:58:21 2024] [debug] loading controller from db
[Mon Jul  8 10:58:21 2024] [debug] setting controller status to 800
[Mon Jul  8 10:58:21 2024] [debug] saving controller to db
[Mon Jul  8 10:58:21 2024] [debug] calculating controller checksum 4ba99a6593094ac35a6b3b800743f8bd
[Mon Jul  8 10:58:21 2024] [debug] loading controller from db

The status codes map to this in backup/backup.class.php:

    const STATUS_CREATED     = 100;
    const STATUS_REQUIRE_CONV= 200;
    const STATUS_PLANNED     = 300;
    const STATUS_CONFIGURED  = 400;
    const STATUS_SETTING_UI  = 500;
    const STATUS_NEED_PRECHECK=600;
    const STATUS_AWAITING    = 700;
    const STATUS_EXECUTING   = 800;
    const STATUS_FINISHED_ERR= 900;
    const STATUS_FINISHED_OK =1000;

Long story short, it's executing and never gets to any finished state.

max_input_vars is at 5000. Bumping it up is an idea, but I don't think this will matter since it is only for GET, POST and COOKIE input variables, which is not the case here since we programmatically kick off these restores and not through a UI. We also do not see any PHP warnings about this, so I don't think we're hitting this limit.

Automated backups are disabled

We have full access to the server, so we can do any cli thing, but again, we already run these backups and restores through CLI (the custom plugin runs them through a cron task), so we are already mitigating any web server wonkiness.

And yes, we've been doing a lot of head scratching too.. At least we're not alone in this I suppose. It's probably something stupid and easily solved, but the journey to that point is an absolute pain.


Viewing all articles
Browse latest Browse all 6815

Trending Articles



<script src="https://jsc.adskeeper.com/r/s/rssing.com.1596347.js" async> </script>