My site has been down now since April. My host has a 2gb limit for my website and evidently it grew to 6.2gb. Once the host discovered my site was too large they cut off my site from writing anymore files. Now my site will not load and at one point showed maintenance mode. Now it doesn't show anything. It says "Site Cannot be Reached". I discovered later that "Backup and Migrate" was the issue. It was backing up without any parameters and the folders grew and grew. My site had archived over 5yrs of backups. I could see how far back the files went with Filezilla but I couldn't delete them. Using the file manager from my host, I could see even less. I am not a programmer and I need someone who could possibly correct the issues, get the site back online and then upgrade to the latest version. My biggest worry is losing all of my users and passwords. My site is a drupal 9 site. I have been rebuilding a new site on a localhost but I don't like the theme choices. As there are thousands, I can't even find anything remotely close to what my site is currently using. My remote site uses Danland and I really like it but it is not supported by drupal 11.x. So there is that too. Can someone point me in the right direction to help get my site back up and running? I don't really have any support other than the forums. I tried Chatgpt and while it can help a little, it creates more headaches than solutions.
wjkjr
Comments
Hi wjkjr,
Hi wjkjr,
Sorry you're dealing with this — this is fixable, but a few things to untangle carefully since data loss risk is real here.
First, don't delete anything yet. The "Site Cannot be Reached" / blank page after maintenance mode usually means PHP hit a fatal error or ran out of disk space mid-write, not that your database or core files are corrupted. The 6.2GB is almost certainly Backup and Migrate's old backup files piling up in
sites/default/files/backup_migrate(or similar) those are just archived .tar.gz/.zip files, safe to remove once you confirm what they are.Steps I'd take, in order:
On the theme concern since Danland isn't compatible with Drupal 11, you'll need to rebuild or pick a new base theme during the upgrade regardless, so that's a separate project from just getting the current site back online.
This is very doable, but honestly, given the data-loss stakes (5+ years of content) and that you're not a programmer, it's worth getting a second pair of hands for at least the recovery step so nothing gets deleted incorrectly. Good luck!
Update to Broken Site
I contacted my host and was able to get access to phpMyadmin. They were able to delete all of the old backups. The site is now at 4.2gb and they set my site to a max of 6gb so I'm at least under the storage threshold. My site will now load but is stuck in maintenance mode. Now all I have to do now is turn off maintenance mode. I tried
UPDATE config
SET data = REPLACE(data, 'b:1;', 'b:0;')
WHERE name = 'system.maintenance';
didn't work.
If I need to find "that extra pair of hands" where do I look?
wjk
Hi wjkjr,
Hi wjkjr,
Glad the site is loading again. The reason your query didn't work is that in Drupal 8 and later, maintenance mode is not stored in the config table. It lives in the key_value table as state, so there was no system.maintenance row for your UPDATE to change.
Before anything else, please export your database from phpMyAdmin (Export → Quick → SQL) so you have a safe copy.
Then run this in phpMyAdmin's SQL tab:
sql
UPDATE key_value
SET value = 'b:0;'
WHERE collection = 'state' AND name = 'system.maintenance_mode';
If your tables have a prefix (for example drupal_key_value), use that table name instead.
After that, clear the cache by emptying (TRUNCATE) the cache_bootstrap, cache_config, cache_container, cache_default, cache_discovery, cache_render, cache_page and cache_dynamic_page_cache tables. If you don't clear them, the site may keep showing the maintenance page. If your host gives you Drush, this does the same in one go:
drush state:set system.maintenance_mode 0
drush cr
Once you can log in as admin, you can also check /admin/config/development/maintenance and make sure "Put site into maintenance mode" is unticked.
Regarding help: you can post a job on the Drupal Association's service provider directory (drupal.org/drupal-services) or ask in the #support channel on Drupal Slack (drupal.org/slack). Since your data is safe in the database, a developer should be able to handle the upgrade (Drupal 9 is end-of-life, so going to 10 first and then 11 is usually the safest path) without touching your users or passwords.
Also, please remember to turn off or limit the scheduled backups in Backup and Migrate so the files folder doesn't fill up again.
Good luck, and feel free to post back if anything fails.
I need to try to get out of
I need to try to get out of maintenance mode first to see exactly what my site is doing. I have a backup but im apprehensive that I can restore the site if something goes sideways. Ill repost on Friday and let you know of any progress.
That's a sensible approach -
That's a sensible approach - take your time with it.
One thing that might help with the apprehension: the SQL query I shared only updates one row in one table. It doesn't touch your content, users, or any other data. And since you already have a backup from phpMyAdmin, you can restore that exact state if anything goes wrong.
Post back on Friday - happy to walk through it step by step if needed.
The site now loads and Im out
The site now loads and Im out of maintenance mode, but my admin menus are missing as well as the sites menus..
Hi wjkjr,
Hi wjkjr,
That's pretty normal after truncating the cache tables by hand instead of doing a proper rebuild — the router and menu links need to regenerate, and just emptying the cache tables doesn't always trigger that on its own.
If you've got Drush, just run
drush cr— that forces a full rebuild including menus and routes, and honestly fixes this most of the time on its own.No Drush? Go to
/admin/config/development/performanceand hit "Clear all caches" there instead. Then check/admin/structure/menuand see if your menus are actually still listed. If they are, it's probably just that the menu blocks got knocked out of their regions — worth checking/admin/structure/blockfor that.If the menus aren't even showing up at
/admin/structure/menu, don't panic yet. TRUNCATE only touched the cache_* tables, not your actual content tables, so the menu data is almost certainly still sitting in menu_link_content in the database even if the UI isn't showing it right now.Try the cache clear first and see where that gets you.
I have hired a developer who
I have hired a developer who said he can get me back up and running. I have talked to him on the phones several times now and drupal is his job. His linkedin page shows him being employed by Aquia and others. He has 20yrs experience with drupal. Just hoping he can get me back up and running. The only thing left I need to do is find a new host as my current one does not allow SSH so composer and drush cannot be used. Any ideas?
thanks
I'm the developer who took on
I'm the developer who took on this project. It was quite the effort. I've recovered hundreds of Drupal sites, but this one was the most complex. The site was a non-composerized Drupal 9 site, that did not have drupal 8 updates run on it when upgrading from Drupal 8 to Drupal 9. On top of that, it was originally a Drupal 5 installation, and the upgrade to D8 had not been the cleanest. The CCK fields were not properly integrated with the system, and therefore not available to views. So the site had some major underlying issues.
On top of this, the site was hosted by a telecom, and appeared to be legacy from the days when telecoms were in the hosting game. The server that had no SSH access, with an archiving agent in the control panel that broke when trying to create archives for FTP download, meaning that a full .zip archive could not be created, and files had to be individually downloaded to create a local development environment.
First thing I did was pull the relevant Drupal directories individually with FTP, and then get a database dump with the control panel for the server. I tried rolling back to Drupal 8 to run the updates, but this broke everything, as the site was not composerized, so all the contrib modules were the wrong versions for D8, and caused fatal errors. I ended up working my magic, got all the updates done on the site, fine tuned backup and migrate, got the site set up with Composer, and committed to Git.
We then got a new server for the site, one with SSH access, allowing for multiple subdomains and environments, that costs 1/3 the monthly fees of the previous server. I deployed the now cleaned up D9 site on the new production server, we pointed the domain at the new server, and the old server can now be decommissioned.
I then set up a staging environment for the system and upgraded from D9 -> D10, as well as ckeditor4 -> ckeditor 5, and after confirmation that it was working, I proceeded with the D11 upgrade. The upgrade is now in testing by wjkjr, and we will likely depoy in the next day or two.
This was a good challenge. It took all my upgrade skills!
Contact me to contract me for D7 -> D10/11 migrations.
Or anything really. I'm friendly, and open to work or conversation.
Thanks for sharing @jaypan,
Thanks for sharing @jaypan, that sounds like a nightmare of an installation to upgrade! I am glad it got in good hands, and completed by you. it only goes to show that you need to allocate the required resources up front for maintenance, using the recommended method (Composer), and keeping Drupal updated continuously. Otherwise, you'll end up paying a bigger prize later.
PS. Not so much an update story, but I have also helped rescue a Drupal site, where the lists were not built with Views, but carefully handcrafted PHP and SQL calls.
PS. Not so much an update
I built a few of those back in the D5/6 days ;p
Contact me to contract me for D7 -> D10/11 migrations.
Or anything really. I'm friendly, and open to work or conversation.
And now I've deployed the new
And now I've deployed the new site to production, on Drupal 11 and PHP 8.5, composerized, gitted, and DDeved site, with the status page showing a full green report. It feels good to have recovered this very broken, no composer, Git or DDev, D9 site, without SSH access, and brought it up to a fully standarized D11 site on a new server.
Contact me to contract me for D7 -> D10/11 migrations.
Or anything really. I'm friendly, and open to work or conversation.
Congratulations! Seeing a sea
Congratulations! Seeing a sea of green checkmarks under Status report and Available updates is always very satisfying.
You could consider sharing some of your findings (scripts, order of steps, etc.) on your blog?
Good idea, I'll put a case
Good idea, I'll put a case study about it.
Contact me to contract me for D7 -> D10/11 migrations.
Or anything really. I'm friendly, and open to work or conversation.
Fantastic, I am looking
Fantastic, I am looking forward to reading it!