Cyber Protect 2023 Bootable Media Issue - Backup Options not Being Applied Properly
I just purchased the latest Cyber Protect license simply to obtain an updated bootable media package since the older TI 2018 version I had was not playing nice with a brand new system I've just built (was giving VGA incorrect parameters error; apparently a known bug in older versions).
The problem is that the newest version of the linux-based rescue media is not honoring the additional or parameters I'm choosing during the backup operation. I'm referring to the optional parameters such as compression level, validate after backup, etc. The only option that does seem to work is archive splitting. Nothing else I set seems to have any effect. For example, backing up a disk with 30GB data with compression set to "none" results in a 7GB file. If I set it to normal or maximum the resulting file is still 7GB. Also, there is no validation process running after backup completes. The backup type I select is "Full" and NOT incremental. Now I'm curious if that choice is being applied correctly or not.
I've been using True Image for over 10 years and have never had any issues with the bootable media until now. Can anyone else confirm the same issue? Is it a bug? I have tried on two different systems with the same result. I've also tried building the rescue media using older versions, or at least as old as I am allowed to download given my subscription only started in 2023. I've tried builds 40338, 40173, and 40107. Same behavior with all of them. The backup completes without error, and I'm able to browse the archive afterwards, but there are times when these options are needed and they are expected to function as they did in older versions.
I've also tried downloading the AcronisCyberProtectHomeOffice2023_AUR_x64.exe (which CP desktop apps prompts to do when choosing universal restore tool). That wizard is slightly different and has a few extra options, but it still results in the same issue with no backup options being applied correctly as chosen.
(btw both PCs I've been testing on are 64-bit UEFI)
140BPM,
Do you have a specific reason why you are using the Linux version of boot media? If not I suggest that you build WinPE/RE media instead and try that version.
Enchantech wrote:140BPM,
Do you have a specific reason why you are using the Linux version of boot media? If not I suggest that you build WinPE/RE media instead and try that version.
I've been using the linux version for over ten years now without issue, and so it's just my go-to default since it's been so reliable in the past. Of course the last license I had which I was still using up until now was TI 2018, so I don't know if bootable media versions released between 2019-2022 would exhibit the same issues or not.
I've been using the linux version for over ten years now without issue, and so it's just my go-to default since it's been so reliable in the past. Of course the last license I had which I was still using up until now was TI 2018, so I don't know if bootable media versions released between 2019-2022 would exhibit the same issues or not.
As I recall in 2019 Acronis moved to using WinPE/RE as the default preferred base for boot media. The Linux based version was relegated to a more or less Legacy status so, I think development on that version is not as it once was.
I would suggest building the WinPE/RE version and give it a try. Nothing to lose but a bit of time really and if it solves the issue great!
Enchantech wrote:I would suggest building the WinPE/RE version and give it a try. Nothing to lose but a bit of time really and if it solves the issue great!
I can try it, but if I build a WinRE boot from CP 2023 app on a Windows 10 PC, can I expect it to work on non-windows OS builds or PCs with different hardware or W11? Part of the reason I used the linux version was that I often image some data drives on a PC running linux OS. Also, the PC I have CP 2023 on right now (W10) is not the PC it will live on permanently. I'm currently building a new PC and want to image that new disk with a completely clean image of Windows 11 Pro on it before installing all of my other apps and then migrating Cyber Protect application over to it. I can certainly try to build the bootable from that new W11 PC to see if there is any difference. Again, the backups seem to work, but the optional parameters are not working as expected.
My experience has been that over the years I've been able to image everything with the linux based boot media without issues or having to inject special drivers and whatnot. It just worked. I only keep Acronis desktop activated on one PC and use that as my main repository, but I do have a need to back up disks attached to two other machines with different OS's and hardware.
Definitely not under active development - the last update apparently was when Build 39184 (11 March 2021) was released (going by the ISO size).
Ian
Ok, built WinRE bootable media directly from the target Windows 11 PC and successfully booted into it. Same exact behavior as the Linux based rescue media. Changing the compression setting has zero impact on final tibx size. I tested all compression options individually. All resulted in identical file size, which was much smaller than even the estimated size using the maximum setting. Also, the option to validate after backup completion does not work with the WinRE flavor either. It completes the backup and presents the success message; no validation happening after backup process.
I also tested all other options with the WinRE such as password protection/encryption and other archive splitting settings. Those all seem to work as expected. It's just compression level and validation check that seem to be useless in both Linux and WinRE bootable media.
All tests I ran with both versions of the bootable media resulted in archives that did validate successfully when checking within the windows desktop app, and I can browse files within just fine. So I suppose all is working with both versions of the boot media. It was just striking at how small the resulting files compared to actual data and even the estimated size of the maximum compression option. That is what is causing me second guess the integrity of the backup process using the boot media.
I really wish these options would work properly again like in older versions. I know they are not 100% required as long as the backups succeed, but sometimes for peace of mind for very important backups I'd prefer no compression just to eliminate one additional variable that could potentially go wrong. Not everyone stores data in the cloud after all.
140BPM,
In general terms the default Normal compression selection in the product is very efficient and should serve most user well. Normally selecting High or Maximum levels achieve only minimal gains is reducing data size while significantly increasing the time taken to complete the backup process. This is primarily due to the fact that High and Maximum compression are third party compression libraries. See Here
How did you determine that Validation is not being performed by the products? Did you verify that validation was not run by checking the Log files in the boot media? Please use the Logs option in the boot media to review all tasks run while the boot media is online.
Additionally, validation is simply a checksum routine which compares that the data in the selected backup has not changed since the backup was initially created. This means that validation should not take an inordinate amount of time to run of course, the larger the backup file the longer validation will take. It may well be that validation is being performed without you realizing it.
140BPM wrote:Ok, built WinRE bootable media directly from the target Windows 11 PC and successfully booted into it. Same exact behavior as the Linux based rescue media. Changing the compression setting has zero impact on final tibx size. I tested all compression options individually. All resulted in identical file size, which was much smaller than even the estimated size using the maximum setting. Also, the option to validate after backup completion does not work with the WinRE flavor either. It completes the backup and presents the success message; no validation happening after backup process.
I also tested all other options with the WinRE such as password protection/encryption and other archive splitting settings. Those all seem to work as expected. It's just compression level and validation check that seem to be useless in both Linux and WinRE bootable media.
All tests I ran with both versions of the bootable media resulted in archives that did validate successfully when checking within the windows desktop app, and I can browse files within just fine. So I suppose all is working with both versions of the boot media. It was just striking at how small the resulting files compared to actual data and even the estimated size of the maximum compression option. That is what is causing me second guess the integrity of the backup process using the boot media.
I really wish these options would work properly again like in older versions. I know they are not 100% required as long as the backups succeed, but sometimes for peace of mind for very important backups I'd prefer no compression just to eliminate one additional variable that could potentially go wrong. Not everyone stores data in the cloud after all.
Hello!
I have checked the issue with our support. We are currently checking the logs in order to find the root cause.
As soon as there is a solution you can expect an email from our side.
Thanks.
Hello Everyone,
here is an update to the opened support ticket concerning the compression of archive:
This is currently expected program behaviour. The new archive 3 format (.tibx) has compression by default, which means that even if the user changes the level to none, the data will still be compressed.
There are some plans to improve the feature in the upcoming program version which is estimated to be released end of August this year. The product documentation will then be updated to reflect the changes.
Thank you Ekaterina for the update on compression.