timelimited

In the global logs I could notice such error log:
Utime failed: Permission denied

You’ll also notice in logs, that’s not where the backup stopped. That’s a different plugin that was blocking 1 file from being backed up that the plugin skipped.

“What you described there, usually happens when you don’t have enough space on the server and indeed uses ZipArchive to create the backup. Please check if you have enough space on the server/machine where you tried to create the backup, you should have at least twice of the total size of your site.”

Filesystem Size Used Avail Use% Mounted on
/dev/root 29G 15G 15G 51% /

As mentioned, I tested for free space.

Upgraded to newest plugin again. On Ubuntu at CLI I ran “sudo php cli-handler.php bmi_backup” and it only output the following and stopped:

/var/www/html/wp-content/plugins/backup-backup-pro/backup-backup-pro.php

This is different than if I were to run it with any previous version of the plugin.

“Also worth to mention that you received permission denied warning instead of incorrect path issue, these messages are different and indeed one is marked as warning which does not stop the process, and other is fatal error which stops the process. In your case it may be possible that your directory permissions requires recursive adjustments.”

That “warning” kills the entire extraction process for the zip resulting in the rest of the process failing.

“In such case, why don’t you migrate the website manually, if you could create script that unzip the file with ZipArchive, you could easily create SCP script that syncs the files and use WP-CLI to perform search-replace or GO script which is most efficient for that?”

Again, the zip that is being created is not compatible with Windows and cannot be extracted.

“indeed uses ZipArchive to create the backup”

Actually, I just looked and even your newest version of the plugin, every line of ZipArchive is commented out like as follows:

// using zipArchive class
// if ($this->lib === 1) {
//
//   // Create DB Dump
//   $this->createDatabaseDump($dbbackupname, $better_database_files_dir, $database_file, $database_file_dir);
//

There is actually a lot of code commented out, especially for a public production product????

“Regarding issues with 1 GB backup you mentioned, based on the debug code, it looks like it was performed on Windows 8 which is deprecated since 2016’s, please consider free upgrade to Windows 10 or 11. Nevertheless we’re not going to support Windows 8.”

I haven’t used Windows 8 even once since it existed. The 1 GB backup is being created on a Ubuntu LINUX machine, so I don’t know what “looks like it was performed on” symptoms you’re seeing, and if you saw the original email with the screenshots, the zip slowly goes over 4GB then suddenly drops to under 1GB, and those are all LINUX screenshots. On the machine that is restoring this as my dev machine, it’s Windows 10 Pro for Workstations 21H2 with 200GB free on an NVMe drive and 16GB of DDR4 memory so I *believe* there shouldn’t be any issues supporting this…….

I’ve updated the live server back to the newest plugin, and as I said:

1. The CLI command stops immediately without actually running

2. The web UI crashes out further in the process. Here’s ANOTHER code: BMI-wOdCIJS2-58811

In addition to that, yes, I could make an entire system to do my backups and transfer the data and restore the data, but that is why we paid you. Was that a mistake?

So, actually went back to 1.3.0 and at the CLI it immediately stopped with no error, warning etc. Went back to 1.2.8, and just get

Checking free space, reserving…
[STEP] [2023-11-18 04:00:37] Aborting backup…
[ERROR] [2023-11-18 04:00:37] Site weights more than 2 GB.

And then it stops.

The server has 17GB of free space, so I’m positive it’s enough.

The WebUI currently is stopping at:

[SUCCESS] [2023-11-18 04:31:46] Table export for: wp_wpmailsmtp_tasks_meta finished (0.00461s)
[STEP] [2023-11-18 04:31:46] Getting data of table: wp_wpr_rocket_cache (178/210, 16.31 MB)
[SUCCESS] [2023-11-18 04:31:47] Table export for: wp_wpr_rocket_cache finished (1.10974s)
[STEP] [2023-11-18 04:31:47] Getting data of table: wp_wpr_rucss_used_css (179/210, 34.86 MB)

With code: BMI-WNizCzZs-85112

“As with all other plugins, the latest Backup Migration plugin version is the most sophisticated, optimized and secure version of the plugin that will work on widest range of WordPress variations than any other previous version. Therefore it is always in user’s best interest to use the latest version of Backup Migration plugin.”

I upgraded back to the newest version of the plugin and tested another backup which resulted in a truncated corrupted zip file under 1GB again.

I took some time and made a manual script for using ZipArchive to extract the zip so that I could analyze the output directly, and it turns out not to be a long file name issue at all. I just told it to extract to a “Temp” folder and received this output: Warning: ZipArchive::extractTo(Temp/wordpress\wp-content\uploads\2023\08/q2-150×150.): Failed to open stream: Permission denied.

So from that, it looks like when the zip is being created, it’s not properly controlling the character set for folders and filenames to make them compatible for Windows and Linux which results in a “/” being in the file structure which of course is not an allowed character on Windows which causes the unzipping operation to fail.

So doing some research and digging into the code, I found that all of the code for “ZipArchive” has been commented out of the zip.php resource file. I uncommented all of that code in testing, and changed all the variables that were forcing it to use PCLZip and still ran into a similar problem where it extracted over 65000 files then ran into the length limit and aborted.

1. You did notice in the 1st post there was a debug code right? So kind of clear that I know where to get those codes.
2. I realize that “the process does not simply consists of zipping/unzipping. Backup plugins do much more than that.” considering I’m a high level Multilanguage programmer that successfully troubleshot why it was overwriting the original backup with a sub backup in the newer plugins.
3. I mentioned zipping / unzipping because it was crashing with a “PCLZIP_ERR_BAD_FORMAT” error due to long file names, and explicitly mentioned that I tested the zip successfully. To explain this further, 7Zip is manifested with support on Windows 10 for longer than 255 characters, while PHP has not been, so when it’s trying to extract something with longer file / directory names it’s failing, and this backup plugin is not explicitly controlling / aware of that and failing with a generic error.

P.S. Here’s the code if you want to look at it -> BMI-0vBnm6sH-76127

I’ve created a partial solution at this point in time:

After re-installing version 1.3.0 of the free and paid version of the plugin, switching to PHP-FPM (8.2), increasing Apache’s memory to 512MB, increasing WordPress memory to 256MB, and some other configuration changes, I was able to successfully get a backup.

I downloaded the backup and tried to restore it through the GUI just for it to fail very quickly. I went to a cmd prompt and ran the restore through the cli-handler.php and within a couple seconds it fails with “PCLZIP_ERR_BAD_FORMAT (-10) : Invalid archive structure”, “Something bad happened…”, “Something bad happened…”, “Call to a member function getMessage() on string”, “Aborting…”.

Opening and manually extracting the zip was successful, though several files it extracted multiple identical copies of. Digging in deeper, the combination of the temporary folder that the plugin uses to extract the file to is creating a path that is too long for Windows (My development machine, which is installed in the standard “C:\Apache\htdocs\” folder.

I tried to apply the long file name registry and group policy edits to extend the character set past 255 characters with no success on restoring this backup.

I also tried to go back to an older version of the plugin but was greeted with “Your plugin (Backup Migration Pro) is newer than current (Backup Migration). Premium version will be disabled unless you update the free plugin.”

What is the point of that?????? If I have a current Backup Migration Pro license, EVERY version of the free plugin should work.

Nevermind. The product video gallery slider doesn’t work for variants so I am not going to be using that plugin, so you can disregard this ticket.

• This reply was modified 1 year, 3 months ago by timelimited. Reason: Added ticket resolved

OK, I’ve posted a support ticket. I figured if API access was possible, having a public ticket about it would be beneficial for creating more sales about the plugin….

”?the thing you described sound like charset incompatibility?” – That would be incorrect. This wordpress site has been backed-up and restored between these two machines multiple times without issues and have never changed the MySQL character sets on any of the databases. This is an issue that I had with the newest version, but as said in the above posts, I found the errors in the program and corrected them and was able to restore the system.

Nevermind…. I went through your code and found the CLI command: php cli-handler.php bmi_restore <backupfile.zip> Running that and fixing a couple issues with how it handles certain MySQL tables I was able to fix it and got the restore to run successfully at a command prompt.

Even with that table emptied out completely, the restore log ends in:

[STEP] [2023-06-20 23:38:31] Started restoration of finer_search_history 6/189 (3.17%) table
[INFO] [2023-06-20 23:38:31] Progress of finer_search_history: 1/2 (50.00%)

I modified the php.ini to also increase the “memory_limit” to 4096M from 2048M, “post_max_size” to 1024M from 256M, “upload_max_filesize” to 1024M from 200M, and “post_max_size” to 1024M from 40M. All that did was allow the browser to stay at 5G memory usage longer, and Apache to go over 2G of memory useage before the restore process failed, though now the restore log ends in:

[STEP] [2023-06-20 23:13:48] Started restoration of finer_search_history 6/189 (3.17%) table
[INFO] [2023-06-20 23:13:48] Progress of finer_search_history: 1/3 (33.33%)

The finer_search_history table has 492 rows at 464KB’s of data, so no reason for it to fail on that. When looking at the table through PHPMyAdmin, the finer_search_history table has been created, but contains no data. I am going to test clearing the data from the live search history table and doing a fresh backup to see if it will restore.

Starting the restore a second time, it starts at 49% and runs for a couple minutes until suddenly within a couple seconds the browsers memory usage goes from ~300MB to over 5GB of memory usage and then the restore fails with the same restore log. I’ve already used WP-Optimize on the database and checked for inconsistencies. The table that finishes successfully is only 332 rows and 224KB, with the next table listed in MySQL having 492 rows and 464KB’s of data. The entire database is only 268 MB, so definitely not a size issue.