我怀疑我的麻烦始于在稳定版本发布后从8.5.x更新到8.6。我可能通过不先回滚到8.5.x而更新到8.6.1来使问题更加复杂。我错过了那张精美的画。无论如何，这是自成为分类法错误的受害者以来发生的一切：
从2018年4月起，我抓取了我的网站的旧备份，并在我的VPS上与遇到此问题的该麻烦的网站（网站A）分开设置了一个新帐户（网站B）。经过一些工作，我能够成功地将Drush支持添加到站点B。即使我在根目录中安装了Drush，它也无法用于站点B，因为它适用于VPS上的站点A和其他Drupal站点。安装Drush后，我成功地在站点B的新帐户上恢复了站点A的备份。我更新了站点B，它在Drupal 8.6.1上似乎正常工作，没有分类错误。
返回到站点A。我在访问站点A时发现，我不再可以正常运行站点。取而代之的是，我看到了与数据库有关的错误，其中包含表明数据库问题的代码。我看到的错误（被截断的形式）与以下内容匹配：
“未捕获的PHP异常Drupal \ Core \ Database \ DatabaseExceptionWrapper：” SQLSTATE [42S22]：找不到列：1054'where子句'中的未知列'block_content_field_data.reusable'：SELECT base_table.revision_id AS版本_id，base_table.id AS ID 从 {block_content} base_table 内联{block_content_field_data} block_content_field_data开启block_content_field_data.id = base_table.id 在哪里（block_content_field_data.reusable IN（：db_condition_placeholder_0））和（block_content_field_data.default_langcode IN（：db_condition_placeholder_1））;数组 （ [：db_condition_placeholder_0] => 1 [：db_condition_placeholder_1] => 1 ） “位于/home/d8wrscorg/public_html/wrscD8/core/lib/Drupal/Core/Database/Connection.php第686行”
在搜索此错误时，我遇到一个答案，建议运行update.php来更新数据库。我无法通过将update.php附加到站点A的URL来运行它，因此我按照建议更改了settings.php，以使我可以访问update.php。运行该命令后，我能够还原站点A。但这产生了一个新问题：站点A现在看起来像我在出现初始错误之前所拥有的站点的旧版本。我通过查看块ID并将其与我在CSS文件中用于站点A的ID进行匹配来确认这一点。
除了看到站点A的旧版本外，我现在无法导航到其他页面。相反，我看到以下错误：
”未找到 在此服务器上找不到请求的URL /drupal/index.php。
此外，尝试使用ErrorDocument处理请求时遇到了404 Not Found错误。”
这对于站点A上的页面和管理菜单中的页面都是正确的。在我使用update.php将网站重新带回来之后，这个问题成为了一个问题。在站点A进行短暂导航以测试问题的程度之后，我遇到了HTTP 500错误，因此我运行过update.php几次，以使站点启动。
一些其他与此问题可能相关的问题：
我已接近VPS上inode的限制。我要求在72小时内临时增加inode。
在使用update.php还原站点A之前，我在错误日志中看到以下错误：
“ PHP致命错误：允许的内存大小已用完67108864字节（尝试分配20480字节）。”
类似这样的多个错误，但是自运行update.php以来它们已消失。我还为php.ini中的站点A分配了64MB。
“命令pm-updatestatus需要更高的引导程序级别才能运行-您[错误] 将需要从功能更强大的Drupal环境中调用drush才能运行此命令。 drush命令“ ups”无法执行。”
我在站点A的文件夹中运行drush命令。运行'drush --version'时，我可以看到版本为8.1.17。我最近从Drush 8.1.13更新了。
鉴于以上信息，是否有人可以分享有关如何在上述站点突然崩溃之前将站点A恢复到其生存期的最新信息？是什么原因导致有关缺少index.php问题的错误？
感谢所有能伸出援手的人。