Corrupt backup shrinks at last second.

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.

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.

Hello @timelimited ,

We are sorry that we could not get back to you any faster.

The reasons why latest premium plugin version works only with the latest free plugin version are purely technical ones. Free plugin, which acts as a core plugin simply has different mechanism in the older versions that are not compatible with the latest premium plugin, which clearly does not work as a stand-alone plugin.

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.

As for your original report of a backup process issues, indeed, the memory readings on the source website were improper and fixing the memory settings on the website/server has probably benefited the process.

As for your migration/restoration, please note that the process does not simply consists of zipping/unzipping. Backup plugins do much more than that.

Please provide a debug code from the site where you ran the Restoration so we can assist you with that.

Nnavigate to the plugin section Troubleshooting > Check advanced options and click on the button:

Share debug info with BackupBliss team

And here’s a screenshot that shows where to get it: https://prnt.sc/lKbjrSAqQudm

Kind regards

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

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.

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.

“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.

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

Hi @timelimited

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.

@timelimited

It is necessary, our premium plugin is nothing else like extension for our free version plugin, it’s similar to theme and child-theme in WP directory.

In the past, e.g. we use CSS from base plugin in most cases of the premium version, but lately we had to update modal windows CSS and if you would be on older version of our free plugin but latest free version, you would be unable to access the plugin due to conflicts with unhidden HTML. Same with Ajax calls, they all have to be up to date and communicate with each other like single plugin.

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.

@timelimited

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?

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.

@timelimited

These days Windows support both and you can combine them without issues, you can test that right away in your MS File Explorer.

Some third party article explaining how it works: https://www.puppet.com/docs/puppet/5.5/lang_windows_file_paths.html and it also provides details why we disables ZipArchive permanently for the restoration process, based on years of experience for this plugin it turns out that ZipArchive can create issues that does not exist and is not stable especially Windows.

At the end I would like to mention that whether it does or not support, our plugin actually adjust paths in case it’s required, we literally have function named “fixDumbWindowsSlashes” in extract.php.

And that’s not all! Wherever it may matter, we do use DIRECTORY_SEPARATOR which is constant determined by used system, instead of plain “/” or “\”.

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.

@timelimited

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.

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.

@timelimited

Lately, we indeed changed extraction path from ABSPATH directory to our plugin directory within protected directory, because of two reasons:

1. Security
2. We noticed that many hosting providers actually does not allow to create directories within ABSPATH directory, caused by permissions or their usage policy.

Because of that we decided to move it there, which following benefits:

1. In case something go wrong, and user will forget to clear leftovers, our plugin removal will also remove all leftover files
2. Our plugin can work properly on much wider amount of hosting providers.

Nevertheless, I am curious what kind of file names you have, in you case the path would be something like:
C:/apache/htdocs/wordpress/wp-content/plugins/backup-backup/includes/htaccess/backup_migration_123123123/wordpress/

Which gives us 115 characters, (we should exclude C:/) which is not included in the length limitation. Worth to mention that NTFS allow filenames up to 256 characters, and due to backward compatibility with MS-DOS you can’t change that with registry, while path length can be changed only in Windows 10 and above, which also requires you to tell the system to use custom path lengths (more details below). In any case it means that your paths overall are larger than 140 characters – as that would be the approx. maximum length of the path after extraction.

Since change of extraction path logic within our plugin, you’re first person with mentioned error.

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.

Worth to mention that group policy is available only in Pro, Education and Enterprise editions of Windows. You can access it within Home version but it won’t work or apply anything.

Warning: ZipArchive::extractTo(Temp/wordpress\wp-content\uploads\2023\08/q2-150×150.): Failed to open stream: Permission denied.

@timelimited

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.

—

I hope that that clarifies everything and dispels your doubts about our plugin.
My apologies you had to wait a bit more than 24 hours for the reply but I was not available yesterday, that’s why I am checking e-mails today on weekend.

If you’re 100% sure that the issue is caused due to path length, I can offer you adjusted version which we will prepare for you that can extract files in ABSPATH directory like in previous versions. Hopefully that should resolve your issue.

In case that will resolve your issue, we’re happy to include official option for such cases which will allow anyone to choose where they want these temporary files extracted.

Let me know if you wish me to process or you want to adjust it on your own – it’s just about changing $this->tmp variable in extract.php, you can uncomment the line above and comment line below, once you do that, you can further decrease the length by modifying temp directory name 'backup-migration_' . $this->tmptime ??
Thank you!

@timelimited, P.s.:
I just noticed your latest post, where you mentioned BMI-WNizCzZs-85112 code.

Versions below 1.3.0 struggled with large site backups via web, they’re also considered as deprecated.

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

Usually it means that the file we tried to access, does not have valid user assigned which prevents anyone from accessing the file/directory.

Make sure to run chmod and chown on ALL of your WP files with proper users and try with 774 permissions if you’re not sure about WS users.

—

The process failed due to timeout caused by Web Server, to resolve the issue you should insert PHP CLI executable path in “Other options” section, or try to disable PHP CLI and use “browser-side” method. To prevent web server from time-outing the process.

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?

I sent an email for premium support yesterday and haven’t heard anything back….

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

The reasons why latest premium plugin version works only

but that is why we paid you. Was that a mistake?

@iclyde If this is your customer then you need to stop here and take it to your site. Customers are not for these community forums and you should know that already.

@timelimited You are this developer’s customer and they made a mistake and can’t support you here. That’s not permitted for anyone’s customers.

For pro or commercial product support please contact the developer directly on their site. This includes any pre-sales topics as well and any pro support.

This is not wordplay and @iclyde needs to stop that now.

As the developer is aware, commercial products are not supported in these forums. I am sure they will have no problem supporting you there.