Support

This was a side-effect of not being able to test against 32-bit versions of PHP while developing an updated version of the JPA format which supports files over 4GiB. Right now, files over 4GiB do get backed up, but because their size cannot be expressed with a 32-bit unsigned integer  (the internal file size structure in JPA format version 1.2) they cannot be extracted, thus breaking the whole extraction process. The new JPA version 1.3 format uses 64-bit unsigned integers which should be fine for quite a while. What was not documented, though, is that trying to convert a PHP intrinsic integer to a 64-bit unsigned integer binary packed format requires a 64-bit version of PHP. That's quite the omission in the PHP manual.

I have addressed this problem once this error message was reported by someone else and wrote a workaround which downgrades backup archives to a 32-bit format, see Version 9.6.1-dev202305150939-rev8929552

Please note that 32-bit versions of PHP will be unable to extract JPA 1.3 archives which are generated by 64-bit versions of PHP. JPA 1.2 archives, generated by older Akeeba Backup versions and 32-bit versions of PHP with Akeeba Backup 9.6.1 (see the development release above; the stable will be released next Tuesday) can be extracted just fine by both 32-bit and 64-bit versions of PHP with the new Kickstart version.

If you plan on extracting backup archive taken on 64-bit systems you will need to use a 64-bit version of PHP. This is easier than you think!

Do remember that IIS uses PHP in FastCGI mode. As a result, you can use different versions of PHP per site. In fact, you can use different installations of PHP. Nothing stops you from having two separate PHP installations of the same PHP version, one 32-bit and one 64-bit, in different folders. You can then assign the desired PHP installation per application pool. I had written about this kind of setup a few years ago when I still had a Windows machine: https://www.dionysopoulos.me/iis-development-server-for-php-on-windows-10.html. Unfortunately, that 2013 Intel NUC I was using to run Windows died and my brief foray into Windows 11 made me decide not to use Windows again unless my life depends on it.

Am I right in understanding that the next stable release of Akeeba backup will function under x86 PHP ?

Correct.

And that only backups created under one version of PHP (x86 OR x64) can be restored BUT only in the same version of PHP ?

No.

Backups taken on 32-bit versions of PHP can be restored on both 32-bit versions of PHP and 64-bit versions of PHP.

Backups taken on 64-bit versions of PHP can only be restored on 64-bit versions of PHP.

You use x86 and x64, but this is wrong. For starters, there is no such thing as x64, it's x86-64. Moreover, x86 refers to an ISA (Instruction Set Architecture), not the width of its registers (32 bits, 64 bits, or whatever). There are 32-bit and 64-bit x86 processors, commonly referred to as Intel/AMD because of the current duopoly on processors using that ISA. There are 32-bit and 64-bit ARM processors. There are 32-bit and 64-bit RISC-V processors. And so on, and so forth. The ISA is not important since the internal binary representation of the data in the archive is always little-endian. Backups taken on a 32-bit version of PHP running on ARM can be restored just fine on a 64-bit version of PHP running on Intel/AMD.

I was thinking as I also use the command line scheduled backups in a batch file that I run as a task, I could always manually trigger a backup by piping the " c:\path\to\php.exe" to the 64 bit version. But that would also show up in the "manage backup" page. As you point out, it wouldn't be the best to have mixed backup versions together. I would need to switch the sites PHP to x64 to extract.

Correct.

Having a completely different build of PHP on the web and on the command line will lead to pain and suffering. Your backups would be taken by a 64-bit version of PHP but then you'd be trying to restore them using a 32-bit version of PHP — this would not work, as I explained above.

The idea is that you can go wider, you cannot go narrower.

32-bit integers can be expressed in 64-bits just fine; not to put too fine a point on it, you just put zeroes in the extra 32 bits.

64-bit integers, however, cannot be expressed in 32-bits. These extra 32-bits would have nowhere to go.

I can again backup using 32 bit php. And restore from 32 bit php archives.

If I am on a 64 bit system, it will create in 64 bit php, and restore 32 and 64 bit archives.

Affirmative.

As I will be running mixed 32 and 64 bit versions on one of my Windows servers, it would be nice if there was a little indication/flag in a backup as to which version it was created?

This is not really possible because it would require being able to read the backup's header. This is not possible when the backup archive is stored remotely. If we instead required a new field in the database it would only work on backups taken with a newer version of Akeeba Backup.

Moreover, it would be incredibly misleading because the JPA 1.2 archive format was also created in 64-bit versions of PHP in prior versions of Akeeba Backup. Marking it as a 32-bit version would confuse our clients and create a torrent of support requests. Marking the JPA version instead would be confusing for everybody, including you, as it might be confused with the software version, again leading to a torrent of support.

Furthermore, in most practical cases we can just make it so that the archive extraction on 32-bit versions of PHP skips over the 64-bit additional archive headers of a JPA 1.3 backup archive. For the vast majority of backup archives (with individual files under 2GiB in size) the user would know, or need to know, the difference. The 32-bit-only JPA 1.2 archives can already extract just fine on 64-bit versions of PHP. For the uses cases with individual files over 2GiB, please do remember that the 32-bit-only JPA 1.2 format did not (and could not) work; the backup archives were broken. Therefore, nothing is lost on pure 32-bit installations.

Finally, the number of 32-bit installations is infinitesimal to begin with. 

With these facts in minds, marking archives in any way in the Manage Backups page would be an anti-feature which would lead to unnecessary confusion and a high number of support requests about a non-issue which is best handled under the scenes. The ONLY correct solution is to allow 32-bit versions of PHP to extract JPA 1.3 backup archives by skipping over their additional 64-bit-only headers.

With regards the x86/x64 nomenclature I was using, the terms x86 and x64 are used to distinguish between versions on the download page

PHP for Windows only runs on the x86 ISA because Windows itself is currently only supported on the x86 ISA by PHP.

Yes, technically speaking, there's an ARM-based build for Windows 10 and 11. However, that build is OEM-only (you cannot download it if you are not a hardware manufacturer with a special contract with Microsoft), therefore it cannot be currently used as a build target for PHP in a continuous integration environment or a build farm. Hence PHP's download page only showing 32-bit and 64-bit builds for the x86 ISA.

Once Windows on ARM becomes a stable thing, if that ever happens, and PHP starts supporting it expect that page (and PECL Windows build listings) to change.

Thank you for your feedback!