Updater Module States cannot update because there is no backup

[rhandom]

Updated updater module on an older 1.7.6 Prestashop site running PHP 7.4. It is on staging and I cloned production there to test the upgrade. When I want to use the module it tells me there is no backup, but cannot see where I can make one in shop. Where is that? Made a manual backup at `https://platform.prestashop.com/project/id/environment/acc/Back-up` but that does not seem to register. Where in store can I make that backup so we can restore from backup when need be?

[Prestashop Addict]

Make your own backup database + sources, it's better.

[El Patron]

In PrestaShop, the “backup” function you see in the Advanced Parameters → Database Backup section only creates a database dump. It doesn’t back up your files (themes, images, modules, etc.) and, even more importantly, there’s no “one-click restore” from that screen. You would still have to manually import the database via phpMyAdmin and restore files via FTP.

That’s why it’s always best to make backups directly in your hosting control panel (cPanel, Plesk, etc.) or via your hosting provider’s backup tool. That way you can restore both the database and the files quickly if the upgrade goes wrong.

• Use your hosting to make a full site backup (database + files).
• The 1-Click Upgrade backup option is optional and limited; it’s mainly a convenience, not a reliable restore method.
• If PrestaShop’s back office is unavailable after an upgrade, you won’t be able to run its restore anyway—only your hosting backups will save you.

[rhandom]

@El Patron tried to do a database backup from advanved paramters and got

LEVEL
FATAL ERROR
INFO
Allowed memory size of 536870912 bytes exhausted (tried to allocate 4096 bytes)
FILE
/vol/site/current/classes/db/DbPDO.php
LINE
156

ON 15.08.25, 08:23

Not sure if and where I can upgrade PHP Memory usage beyond 512MB. I checked via shell as root and saw

cat  /etc/php/7.4/cli/php.ini |grep memory_limit
memory_limit = -1

so we seem to be at max but not sure if and now I could get more. Also, why the database dump needed that much. But I do see several very large tables with PHPMyAdmin:

Table	Action	Rows  	Type	Collation	Size  Descending	Overhead
	ps_guest	  	 Browse Browse	 Structure Structure	 Search Search	Insert Insert	 Empty Empty	 Drop Drop	~95,110,861	InnoDB	utf8mb3_general_ci	9.3 GiB	-
	ps_connections	  	 Browse Browse	 Structure Structure	 Search Search	Insert Insert	 Empty Empty	 Drop Drop	~48,993,675	InnoDB	utf8mb3_general_ci	5.8 GiB	-
	ps_connections_source	  	 Browse Browse	 Structure Structure	 Search Search	Insert Insert	 Empty Empty	 Drop Drop	~1,805,698	InnoDB	utf8mb3_general_ci	869.0 MiB	-
	ps_pagenotfound	  	 Browse Browse	 Structure Structure	 Search Search	Insert Insert	 Empty Empty	 Drop Drop	~6,594,855	InnoDB	utf8mb3_general_ci	724.6 MiB	-
	ps_search_index	  	 Browse Browse	 Structure Structure	 Search Search	Insert Insert	 Empty Empty	 Drop Drop	~7,809,921	InnoDB	utf8mb3_general_ci	566.8 MiB	-
	ps_product_lang	  	 Browse Browse	 Structure Structure	 Search Search	Insert Insert	 Empty Empty	 Drop Drop	~225,295	InnoDB	utf8mb3_general_ci	498.6 MiB	-
	ps_storecom_imagefile	  	 Browse Browse	 Structure Structure	 Search Search	Insert Insert	 Empty Empty	 Drop Drop	~1,295,805	InnoDB	utf8mb3_general_ci	454.0 MiB	-
	ps_presta_ts_emp_live_feed_update_value	  	 Browse Browse	 Structure Structure	 Search Search	Insert Insert	 Empty Empty	 Drop Drop	~6,417,949	InnoDB	utf8mb3_general_ci	444.9 MiB	-
	ps_stripe_official_processlogger	  	 Browse Browse	 Structure Structure	 Search Search	Insert Insert	 Empty Empty	 Drop Drop	~188,657	InnoDB	utf8mb4_general_ci	168.6 MiB	-
	ps_presta_ts_employee_live_feed_data	  	 Browse Browse	 Structure Structure	 Search Search	Insert Insert	 Empty Empty	 Drop Drop	~716,301	InnoDB	utf8mb3_general_ci	133.7 MiB	-
	ps_statssearch	  	 Browse Browse	 Structure Structure	 Search Search	Insert Insert	 Empty Empty	 Drop Drop	~2,100,347	InnoDB	utf8mb3_general_ci	109.6 MiB	-

Some or all of the large ones seems to be statics related. Still learning more about them But perhaps I can remove them somehow unless client has issues with it and we lose nothing vital.

As for general upgrade, I still cannot use it using the Update Module. Prestahop mentioned this

Quote

We have reapplied rights and ensured everything is ok server-side, we haven't found anything that can explain this behavior.
Your problem seems more related to an applicative issue.
Our support do not handle applicative issues, only server/infrastructure issues.
I can route your ticket to the applicative support team "Prestashop Care", do you want to be put in touch with them ?

I however am taking over this project / site and did not change files / directories. Just made a clone of the production site as we need to upgrade . And I still cannot press the button to upgrade  Perhaps I need to upgrade to Prestashop 1.7.8 the manual way by updating the Gitlab repository and testing on development .

Edited August 15 by rhandom (see edit history)

[rhandom]

When I tried to update via the terminal it hung and failed. Backup was taking too long:

 

INFO - Database backup: 214 table(s) left...
INFO - === Step backupDb
INFO - Database backup: 214 table(s) left...
INFO - === Step backupDb
INFO - Database backup: 214 table(s) left...
INFO - === Step backupDb
Connection to acc-prestashop-xxxxxxx.prestashop.sh closed by remote host.
Connection to acc-prestashop-xxxxxx.prestashop.sh closed.
client_loop: send disconnect: Broken pipe

I realized the second time I tried that the previous backup had caused issues because I got another error

ssh -p 2289 [email protected]
Welcome to Ubuntu 20.04.6 LTS (GNU/Linux 6.6.73-zfs.2.2.7-165 x86_64)

 * Documentation:  https://help.ubuntu.com
 * Management:     https://landscape.canonical.com
 * Support:        https://ubuntu.com/pro

Expanded Security Maintenance for Infrastructure is not enabled.

39 updates can be applied immediately.
To see these additional updates run: apt list --upgradable

22 additional security updates can be applied with ESM Infra.
Learn more about enabling ESM Infra service for Ubuntu 20.04 at
https://ubuntu.com/20-04

New release '22.04.5 LTS' available.
Run 'do-release-upgrade' to upgrade to it.

================================================================================
  ____                        _                   _                     
 |  _ \   _ __    ___   ___  | |_    __ _   ___  | |__     ___    _ __  
 | |_) | | '__|  / _ \ / __| | __|  / _` | / __| | '_ \   / _ \  | '_ \ 
 |  __/  | |    |  __/ \__ \ | |_  | (_| | \__ \ | | | | | (_) | | |_) |
 |_|     |_|     \___| |___/  \__|  \__,_| |___/ |_| |_|  \___/  | .__/ 
                                                                 |_|    

Project: Site
Environment: Staging
Application: PrestaShop
Stack item: PrestaShop
Variation: ACC - S
================================================================================
cd build/
php cli-upgrade.php --dir=kanri --action=UpdateCheck
Could not open input file: cli-upgrade.php
cd modules/autoupgrade/
php cli-upgrade.php --dir=kanri --channel=minor



INFO - === Step upgradeNow
INFO - Starting upgrade...
INFO - Shop deactivated. Now downloading... (this can take a while)
INFO - === Step download
INFO - Download complete. Now extracting...
INFO - === Step unzip
INFO - File extraction complete. Now backing up files...
INFO - === Step backupFiles
INFO - All files saved. Now backing up database
INFO - === Step backupDb
WARNING - [INTERNAL] /root/build/modules/autoupgrade/classes/Task/Upgrade/BackupDb.php line 143 - bzopen(/root/build/kanri/autoupgrade/backup/V1.7.6.5_20250815-103347-473f0867/auto-backupdb_000001_V1.7.6.5_20250815-103347-473f0867.sql.bz2): failed to open stream: No such file or directory
ERROR - Unable to create backup database file /root/build/kanri/autoupgrade/backup/V1.7.6.5_20250815-103347-473f0867/auto-backupdb_000001_V1.7.6.5_20250815-103347-473f0867.sql.bz2.
INFO - Error during database backup.
Connection to acc-prestashop-xxxxxx.prestashop.sh closed by remote host.
Connection to acc-prestashop-xxxxxx.prestashop.sh closed.

So did a restore from production for staging again.

 

Did read about removing or emptying ps_guest , ps_connections and a few on 

 and also on turning of statistics. Looking into that.

Edited August 16 by rhandom (see edit history)

[rhandom]

I could perhaps manually clean the stats tables but more thinking about using https://addons.prestashop.com/fr/performance-site/21344-nettoyage-avance-et-optimisation-boutique.html . Once done I hope the older updater module - despite me upgrading it - can backup and then upgrade things.

[El Patron]

why are you not using the hosting backup?  As mentioned earlier, even if you  manage  to get module back up if you lose access to admin you can not restore. I've never used this module method nor have I ever seen someone that was using it.  I have see on some shops the data stored there from some long go backup which was old and just taking up space.  backups should be done via hosting....you should be working on your product catalog and selling them not messing with a ps module backup.  Joomla has one but you could use a direct link when admin was broken to restore...good luck

[rhandom]

I can use the hosting backup and I do @El Patron . The issue is the command line tool to use the Updater module forces me to backup before an update. Seems the current version does not allow a bypass:

cd modules/autoupgrade/
php cli-upgrade.php --dir=kanri --channel=minor --skip-backup=1



INFO - === Step upgradeNow
INFO - Starting upgrade...
INFO - Shop deactivated. Now downloading... (this can take a while)
INFO - === Step download
INFO - Download complete. Now extracting...
INFO - === Step unzip
INFO - File extraction complete. Now backing up files...
INFO - === Step backupFiles
INFO - All files saved. Now backing up database
INFO - === Step backupDb
WARNING - [INTERNAL] /root/build/modules/autoupgrade/classes/Task/Upgrade/BackupDb.php line 143 - bzopen(/root/build/kanri/autoupgrade/backup/V1.7.6.5_20250820-033427-41d24756/auto-backupdb_000001_V1.7.6.5_20250820-033427-41d24756.sql.bz2): failed to open stream: No such file or directory
ERROR - Unable to create backup database file /root/build/kanri/autoupgrade/backup/V1.7.6.5_20250820-033427-41d24756/auto-backupdb_000001_V1.7.6.5_20250820-033427-41d24756.sql.bz2.
INFO - Error during database backup.

I just want to upgrade , but upgrade this way demands a backup which fails , probably due to huge tables and lack of memory (512MB given for PHP Memory) . 

Looking into this option now via Gitlab / Git I:

# PrestaShop 1.7.6.5 to 1.7.8.11 Upgrade Plan

## Overview
This upgrade plan addresses backup issues caused by over 1 million entries in the `ps_guest` table. The manual upgrade approach using Git provides better control and avoids the problematic auto-upgrade process.

## Environment Setup
- **Git Repository**: `ssh://[email protected]/site/site.git`
- **Current Version**: PrestaShop 1.7.6.5
- **Target Version**: PrestaShop 1.7.8.11
- **Admin Directory**: `/kanri/` (custom renamed from `/admin/`)

## Step-by-Step Process

### 1. Initial Setup
- [ ] Clone production to development environment
- [ ] Verify GitLab git repo gets updated with changes
- [ ] Download PrestaShop 1.7.8.11 to local computer
- [ ] Extract the PrestaShop 1.7.8.11 files locally

### 2. Git Branch Management
- [ ] Create new git branch: `prestashop-1.7.8-upgrade`
  ```bash
  git checkout -b prestashop-1.7.8-upgrade
  ```
- [ ] Change development server Git branch from `master` to `prestashop-1.7.8-upgrade`
- [ ] This prevents overwriting staging and production that use `master`

### 3. File Overwriting Strategy

#### ✅ SAFE TO OVERWRITE (tracked in Git)
Core PrestaShop files that should be updated:
- `/app/` - Symfony app core
- `/bin/` - Console scripts  
- `/classes/` - Core PHP classes
- `/controllers/` - Core controllers
- `/src/` - Modern Symfony code
- `/js/` - Core JavaScript
- `/localization/` - Country/language data
- `/pdf/` - PDF templates
- `/tools/` - Core tools
- `/vendor/` - Composer dependencies (NEW in 1.7.8)
- `/var/` - Symfony var directory (NEW in 1.7.8)
- Core files: `autoload.php`, `index.php`, `init.php`, etc.
- `/themes/classic/` - Default theme
- `/themes/_libraries/` - Core theme libraries

#### ❌ DO NOT OVERWRITE (gitignored for good reasons)
**Customizations:**
- `/modules/` - Custom/paid modules
- `/override/` - Code customizations  
- `/themes/` (except classic) - Custom theme

**Data:**
- `/img/` - Product images, logos
- `/upload/` - Customer uploaded files
- `/cache/` - Generated cache files
- `/download/` - Download files

**Configuration:**
- `/config/config.inc.php` - Database credentials
- `/config/settings.inc.php` - Shop settings

**Admin folder:**
- `/kanri/` - Keep the renamed admin folder

#### ⚠️ SPECIAL HANDLING NEEDED
**Admin folder merger:**
- The new 1.7.8.11 has `/admin/` directory
- Merge these core files into existing `/kanri/` directory
- Keep specific admin configurations
- Update core admin functionality

### 4. File Updates
- [ ] Overwrite all ✅ directories/files with 1.7.8.11 versions
- [ ] Keep all ❌ directories/files unchanged
- [ ] Manually merge admin files from new `/admin/` into existing `/kanri/`
- [ ] Add new files specific to 1.7.8.11:
  - `composer.lock` (updated dependencies)
  - `phpstan.neon.dist` (new file)
  - Files in `/install/upgrade/` directory

### 5. Git Operations
- [ ] Stage all changes:
  ```bash
  git add .
  ```
- [ ] Commit changes:
  ```bash
  git commit -m "Upgrade PrestaShop core to 1.7.8.11"
  ```
- [ ] Push to GitLab:
  ```bash
  git push origin prestashop-1.7.8-upgrade
  ```
- [ ] Changes should automatically sync to development server

### 6. Server-Side Setup
- [ ] SSH into development server
- [ ] Install new Composer dependencies:
  ```bash
  composer install --no-dev --optimize-autoloader
  ```
- [ ] Run database upgrade script:
  ```bash
  php /install/upgrade/upgrade.php
  ```

### 7. Testing Checklist
- [ ] Admin panel (`/kanri/`) loads and functions correctly
- [ ] Frontend displays properly with custom theme
- [ ] All custom modules work correctly
- [ ] PHP 7.4 compatibility verified
- [ ] Database upgrade completed successfully
- [ ] Order process works end-to-end
- [ ] Payment modules function correctly
- [ ] Search functionality works
- [ ] Performance is acceptable

### 8. Deployment to Staging/Production
**Only after thorough testing:**
- [ ] Merge branch to master:
  ```bash
  git checkout master
  git merge prestashop-1.7.8-upgrade
  git push origin master
  ```
- [ ] Switch staging server to updated `master` branch
- [ ] Test staging environment
- [ ] Switch production server to updated `master` branch

## Risk Mitigation
- **Easy rollback**: Simply switch Git branch back if issues arise
- **Zero production risk**: Testing happens on isolated branch
- **Preserves customizations**: Git ignore strategy protects custom files
- **Version control**: Complete history of changes tracked

## Expected Benefits
- Resolved backup issues with large `ps_guest` table
- Updated security patches and bug fixes
- Better performance with newer codebase
- Preparation for future PHP version upgrades

## Notes
- The ps_guest table issue should be resolved in the newer version
- All custom modules need compatibility verification
- Custom theme may need minor adjustments
- Database backup should work properly after upgrade

 

Edited August 20 by rhandom (see edit history)

[El Patron]

Hi, I hope this helps, basically 

When you ran it in the back office, the DB backup failed with a “memory exhausted” error.

When you ran it from CLI, the same backup step failed trying to create the compressed .bz2 file.

In both cases the upgrade never started, because the module refuses to continue if its own backup didn’t complete.

Since you’re already making backups at the hosting level (which is the safer way anyway), you don’t need PrestaShop’s built-in backup here. You can disable it:

Option 1: Back office

In Advanced Parameters → 1-Click Upgrade → Options, simply uncheck “Backup my database” (and even “Backup my files” if you don’t need those). Then run the upgrade from the admin again. The upgrade will proceed without trying to dump your large database.

Option 2: CLI

If you prefer the command line, you can achieve the same thing:

• On legacy CLI (cli-upgrade.php): edit adminXYZ/autoupgrade/config.json and set "skip_backup": 1.
• On the newer Update Assistant (bin/console): just run php bin/console update:start without calling backup:create.

for db clean up here is guide your can follow.

[rhandom]

Installed Update assistant again. Upgraded to 7.3 . Then went to advanced parameters. Nothing there.

Then to Update assistant where again I could only update after doing a backup. When I went back to module manager I can funnily enough no longer see Updater Module listed.

Then I went to the command line again 

cd build/modules/autoupgrade/
ll
total 299
drwxr-sr-x  13 root root     48 Oct  1  2024 ./
drwxr-sr-x 137 root root    139 Oct  3  2024 ../
-rw-r--r--   1 root root   2320 Jul 15  2020 AbstractLogger.php
-rw-r--r--   1 root root  28216 Jul 15  2020 AdminPreferences.php
-rw-r--r--   1 root root  76342 Jul 15  2020 AdminSelfTab.php
-rw-r--r--   1 root root    626 Feb 28  2024 AdminSelfUpgrade.gif
-rw-r--r--   1 root root   1884 Jul 15  2020 FileLogger.php
-rw-r--r--   1 root root  10329 Aug 27  2024 LICENSE.md
-rw-r--r--   1 root root   5467 Aug 27  2024 README.md
-rw-r--r--   1 root root   4373 Jul 15  2020 Readme.md
-rw-r--r--   1 root root   2252 Aug 27  2024 ajax-upgradetab.php
-rw-r--r--   1 root root   3026 Aug 27  2024 ajax-upgradetabconfig.php
-rw-r--r--   1 root root   1786 Jul 15  2020 alias.php
-rw-r--r--   1 root root   6190 Aug 27  2024 autoupgrade.php
drwxr-sr-x  11 root root     34 Aug 16 00:58 classes/
-rw-r--r--   1 root root   1717 Aug 27  2024 cli-rollback.php
-rw-r--r--   1 root root   1893 Aug 27  2024 cli-updateconfig.php
-rw-r--r--   1 root root   2830 Aug 27  2024 cli-upgrade.php
-rw-r--r--   1 root root    961 Aug 27  2024 composer.json
-rw-r--r--   1 root root 134925 Aug 27  2024 composer.lock
-rw-r--r--   1 root root    488 Aug 27  2024 config.xml
-rw-r--r--   1 root root    498 Jul 15  2020 config_.xml
-rw-rw-r--   1 root root    529 Aug 27  2024 config_fr.xml
-rw-rw-r--   1 root root    523 Mar  3  2021 config_ja.xml
drwxr-sr-x   3 root root      3 Oct  1  2024 controllers/
-rw-r--r--   1 root root    155 Aug 27  2024 crowdin.yml
drwxr-sr-x   2 root root      4 Oct  1  2024 css/
drwxr-sr-x   2 root root      7 Oct  1  2024 db/
....

no config.json there. And all files not updated for like a year though I just reinstalled this module. Very odd. Did also check admin auto upgrade as you mentioned :

pwd
/root/build/kanri/autoupgrade
ll
total 25
drwxrwsr-x  6 root root     8 Aug 15 05:18 ./
drwxr-sr-x  9 root root    30 Aug 15 03:36 ../
drwxrwsr-x  4 root root     5 Aug 20 01:34 backup/
drwxrwsr-x  2 root root     3 Aug 20 01:34 download/
-rw-rw-r--  1 root root     8 Aug 15 03:52 filesToBackup.list
drwxrwsr-x 27 root root    37 Aug 20 01:34 latest/
-rw-rw-r--  1 root root 22076 Aug 15 05:18 tablesToBackup.list
drwxrwsr-x  2 root root     2 Aug 15 03:36 tmp/

No config.json there either.

Checked backup directory 

pwd
/root/build/kanri/autoupgrade/backup
ll
total 657555
drwxrwsr-x 4 root root         5 Aug 20 01:34 ./
drwxrwsr-x 6 root root         8 Aug 15 05:18 ../
drwxrwsr-x 2 root root       179 Aug 15 05:18 V1.7.6.5_20250815-053623-7b8f08ce/
drwxrwsr-x 2 root root         2 Aug 16 01:05 V1.7.6.5_20250816-030409-38fee9be/
-rw-rw-r-- 1 root root 712757425 Aug 15 03:52 auto-backupfiles_V1.7.6.5_20250815-053623-7b8f08ce.zip

so a backup is there from the 15th.

Perhaps adding that updater module does not work properly and neither does the upgrade for some reason.

[rhandom]

Made a new branch and will see if I can test that later on on development server. Commands used for getting Prestashop 1.7.8.11, merging new files into existing setup on separate branch, adding branch to Gitlab:

cd ~/code/site/
git status
git pull origin master
git log --oneline -10
git checkout -b prestashop-1.7.8-upgrade
wget https://github.com/PrestaShop/PrestaShop/releases/download/1.7.8.11/prestashop_1.7.8.11.zip
unzip prestashop_1.7.8.11.zip
unzip prestashop.zip -d prestashop_1.7.8.11/
mkdir prestashop_1.7.8.11
unzip prestashop.zip -d prestashop_1.7.8.11/
ls -la
ls -la prestashop*
unzip prestashop.zip -d prestashop_1.7.8.11/
pwd
mkdir prestashop_new
ls -la --time-style=full-iso | grep "2025-08-23"
unzip prestashop_1.7.8.11.zip -d prestashop_new
cd prestashop_new
unzip prestashop.zip
ls -la
cd ..
pwd

# Sync new PrestaShop core files
rsync -av --delete prestashop_new/app/ app/
rsync -av --delete prestashop_new/classes/ classes/
rsync -av --delete prestashop_new/controllers/ controllers/
rsync -av --delete prestashop_new/src/ src/
rsync -av --delete prestashop_new/js/ js/
rsync -av --delete prestashop_new/tools/ tools/
rsync -av --delete prestashop_new/localization/ localization/
rsync -av --delete prestashop_new/pdf/ pdf/

git status
git status > ~/Desktop/status.text
git diff --stat
git diff --stat > ~/Desktop/stat.txt
git diff -- autoload.php
git diff -- index.php
git diff -- autoload.php

# Copy updated core files
cp prestashop_new/autoload.php .
cp prestashop_new/index.php .
cp prestashop_new/init.php .
cp prestashop_new/images.inc.php .
cp prestashop_new/composer.lock .
cp prestashop_new/phpstan.neon.dist .

# Sync updated classic theme
rsync -av --delete prestashop_new/themes/classic/ themes/classic/
ls prestashop_new/themes/ | grep _core

# Merge admin (into custom /kanri folder)
rsync -av prestashop_new/admin/ kanri/ --exclude="*.php" --exclude="autoupgrade/"

git status > ~/Desktop/status-v2.text
ll
cd kanri
ls -lh
git add .
git commit -m "Upgrade PrestaShop core to 1.7.8.11"
git status
git add .
git push origin prestashop-1.7.8-upgrade
git status
git branch
cd ..
git add .
git commit -m "all files, not just kanri directory"
git push origin prestashop-1.7.8-upgrade
git status
git log --oneline -3
git branch -r

Might write a post about all this one day. But first let's see if this will all work in the end without crashing development server store on Prestashop Platform.