ATIH Backups longer not shorter time

I've had mixed results.  It feels like it can take longer at times (not drastically) for backups.  I believe the new .tibx has better algorithms for data integrity, which could cause some additional time, but how much difference are you seeing compared to before?

If you are validating, then YES, it will take longer.  ATI 2020 seems to be validating all backup chains and not just the current one so validation is compounding the overall time the more chains you have.  This has been reported several times and being looked into by Acronis.

Thank you very much for your helpful reply, Bobbo!

Yes I always validate; honestly based upon validation times I thought versions of ATIH previous to 2020 were validating all links in the chain too...but what I'm seeing time-wise does make it seem like ALL chains are now being validated.  Which could explain why the issue is getting worse as I fill the storage space with more chains.

At first it seemed like Incrementals 'just' took as long as Fulls, but now as I said it's worse.  For example, a Full that used to take an hour now takes like 5.  And the same 5 for an Incremental that used to take 15 minutes.

(The exception I think is the ATIH2020 boot media, I think it still takes the prior, acceptable, amount of time.)

Thank goodness this is being looked into as it is egregiously unacceptable; so VERY unacceptable they should have contacted users and issued refunds.

Thank goodness I use boot media to backup my HDD w/1 TB of data on it, and 10TB of chains backed up; with this bug in the OS-version each weekly backup would tie up the PC for at least the whole week maybe multiple weeks; THAT is what I mean by egregiously unacceptable, as it's literally impossible to do a weekly backup that takes multiple weeks to run.

Acronis messed up big on this one.  Thank goodness for this forum.

Glad to have helped (at least identify the issue).  I fully agree - I was told in another thread about this, it was by design, but continue to question the behavior.  Acronis Backup 12.5 (and Backup versions before it) have been using .tibx for quite some time and my recent testing shows that it only validate the backups in the current chain so I don't see why this would/should be different in True Image.  I believe it is a bug and suggest to continue submitting feedback about your experience within the app too - log it with the developers as much as possible!

Thank you very much Bobbo.  To say you "question the behavior" is very diplomatic.

I'm truly astonished by the reply I just got this morning from Pramod Tungal at Acronis:

"If I understand you correctly, you're are validating backups using Acronis True Image 2020 and it is validating all the chains of the backups instead of only the weekly backup.

I would like to inform you that tibx format for Acronis True Image 2020 exhibits this behavior by design. I am sorry, your experience did not meet your expectations.

As for the refund or an upgrade to Acronis True Image 2021, I will need to check with management and will keep you posted of any updates furnished."

This was in response to my ticket:
"I learned at https://forum.acronis.com/comment/519468#comment-519468
that the reason my ATI2020 backups take dozens of times longer to run now is that it's not just running Verify on the chain I've created, but on all the chains.

Because of this, some of my weekly backups take weeks to run.  Naturally this makes it impossible to run them.  At first this bug wasn't as noticeable, but it sure is now that more chains accumulate over time.

This has resulted in my turning instead to the very inconvenient boot media to create my backups.

So much here is unacceptable:

It's unacceptable that I had to go to the forum to discover the bug.  Such a major bug should have resulted in you contacting users about it.

I would like to know when this bug will be fixed.  (I wish I could have participated in the Beta program to help save you from this embarrassment...but I don't have spare computers, and one can't run both the Beta *and* the official release.)

This bug has already resulted in my computers being on for a total of weeks more than they would have been on otherwise, and thus cost me a considerable amount in electricity.  So much I already feel you owe me a refund; or credit for a free ATI2021, your choice."

So this morning I have replied:
"Validating all chains used to be optional, and as you can see from my original email it is untenable (or to be less diplomatic, it is insane) not to have it be optional, in that it causes a (for example daily) backup to take possibly weeks; please escalate this feedback."

I don't know what to do.  I guess I need to fall back to a previous version; since I skipped ATIH2019 I guess I'll be falling back to ATIH2018.  It's a shame that the provider of the best backup software (the most vital software there is) seems to be out of their minds.  I hope the company doesn't fail because of this; they may need some personnel turnover.

Did it not occur to anyone that the objective of someone who backs up will be to have as many chains as possible?  Just for one example I've got a 12TB HDD solely dedicated to backing up a drive with 1TB of data on it; so every time I run a daily incremental they imagine it's appropriate and tenable to force me to take weeks to validate 12TB worth of chains?

Coyote, this is one of the reasons that I have never included validation with any of my backups and still do not do so with 2020. 

Validation, for me, is only a cosmetic check that does not guarantee that the file will be anything other than 'as is' and not a guarantee that it will result in a successful recovery.  It has always been a checksum recalculation exercise, so if the data going into the archive is bad, the checksum will be for that bad data...! 

The only real test is to check the archive contents by exploring them, or mounting the archive, or recovering to another drive etc.

Extending validation so that it checks each and every file ever created for a backup task, covering multiple different backup chains, only serves to consume far more time and cause frustration to users.

The only real fixes for this issue are to provide an option for users to select if only the current chain or X number of chains should be validated, or else revert to the previous behaviour of only checking the current chain.

The alternative approach is to change the backup approach, and only ever create single chains for a backup task.  Creating a new task when a new chain is to be made.

coyote wrote:

 

This has resulted in my turning instead to the very inconvenient boot media to create my backups.

 

I also use this option in 2020. Above all, the question arises here for me;
Ati opted for the tibx and the strong slowdown of the product. I as a customer see no advantage but not asked but forced to dodge alternatives. 

I am not including validation with any of my backups but am seeing this increasing full backup times within a chain also.  First full backup is 4 hours, 2nd full backup is 10 hours and third full backup was estimated at 20 hours before I cancelled.  ATI 2019 full backup time was a consistent 4 hours.  It appears as if something odd is going on with ATI 2020.  I have a pending support ticket and have provided log information to support.

Thank you very much for the responses!

I'm about to begin drafting a letter to the Acronis CEO, but first:

@Steve Smith
"this is one of the reasons"

Well technically "this" (lack of option to not validate all chains) is a new issue.

"a checksum recalculation exercise, so if the data going into the archive is bad, the checksum will be for that bad data...!"

I'm fascinated!  Are you sure it isn't more than that; more than a simple checksum validations?  Doesn't it also (like the other backup products I've used this last quarter century) verify that the image is recoverable?

As for checksum validation, you're right I could live without that.  But if something were to go wrong in the image file creation such that it would not support a recovery operation, I think I want to know that; just once, after creation, not every single time I do a backup months of chains later.  In other words, if ATI is worth it's salt...

"The only real test is to check the archive contents by exploring them, or mounting the archive, or recovering to another drive etc."

it does something like simulate a mount operation when the verify is run.  While your suggestion of manual mounting would be vastly faster, I can't imagine anyone wants to do that manually.

"The only real fixes for this issue are to provide an option for users to select if only the current chain or X number of chains should be validated, or else revert to the previous behaviour of only checking the current chain."

Under Options|Advanded|Validation ATI2020 provides the exact two options it always has, but with 2020 the second option is not honored:

"Validate backup when it is created" (Which I've always checked, but may reconsider if my hypothesis above stands corrected.)
"Validate backup regularly|Various scheduling options" (Which I've never checked)

So technically the previous behavior was to honor this setting instead of ignore it.

"Creating a new task when a new chain is to be made."

I'd rather fall back to ATI2018 than waste time with that.

@Greg Moore
Wow, very odd that this issue is messing with you without validation enabled.  However, as I noted above, what I think 2020 simply does is ignore the "Validate backup regularly" setting; apparently whether one validates upon creation or not.

Nothing should come out of beta with such a huge issue; someone should be demoted back below their level of incompetence.  Yes, I am very upset.

"a checksum recalculation exercise, so if the data going into the archive is bad, the checksum will be for that bad data...!"

I'm fascinated!  Are you sure it isn't more than that; more than a simple checksum validations?  Doesn't it also (like the other backup products I've used this last quarter century) verify that the image is recoverable?

When you make a backup image, it stores checksums at 'Points in Time' throughout the image (hence why you will see issues reported in the forums for PIT's errors), then on a validation, it reads back the file and recalculates the checksum to compare with the stored values.  If all matches, then validation is successful, but this just tells you that the file remains unaltered from when it was created.  If there was any issue latent on the system being backed up, that will also be present in the backup image!  There is no way for validation to state that the image is recoverable to my knowledge!  That can only be proven by doing a recovery using it etc..

Under Options|Advanded|Validation ATI2020 provides the exact two options it always has, but with 2020 the second option is not honored:

"Validate backup when it is created" (Which I've always checked, but may reconsider if my hypothesis above stands corrected.)
"Validate backup regularly|Various scheduling options" (Which I've never checked)

So technically the previous behavior was to honor this setting instead of ignore it.

Sorry, but those 2 options just control how validation is scheduled, i.e. as part of the backup task process - immediately on completion of the backup, or else to be scheduled at a later time.  The options offer nothing to say only validate the current chain or the last 2 chains etc.  In ATI 2020, the validation is performed on all chains whether that be 1 or 10 or 50 chains!

Thank you very much, Steve!

"There is no way for validation to state that the image is recoverable to my knowledge!"

I see.  Then I agree I might as well not bother with validation.

Just in case (though I'm not gonna believe them over you!) I'm gonna ask Acronis support if validation tells one an image is recoverable, not just as it was when created.

"those 2 options just control how validation is scheduled"

Ooops of course you're right.  The 2nd option provides for *additional* scheduled validations, it's not about the validation that accompanies backups.

Well, I like that I can opt out of the scheduled validations.  And I don't support their decision to validate every chain when every backup is created if one wants the backup itself validated; this makes the product unusable for me.

See KB 46310: Acronis Backup for VMware: Troubleshooting Validation Failures - which while for a completely different application has some clear statements from Acronis on what validation is!

Introduction

Validation - an operation that checks the possibility of data recovery from a backup.

Validation of a virtual machine backup calculates a checksum for every data block saved in the backup. This procedure is resource-intensive.

While the successful validation means a high probability of successful recovery, it does not check all factors that influence the recovery process. If you back up the operating system, only a test recovery to new/existing virtual machine or running virtual machine from the backup can guarantee successful recovery in the future.

Another, older KB document - KB 3288: New in Acronis True Image Home 2010 - shows how some functionality around validation has been lost in later versions of ATI..!

Selective validation - Validate only the backup that you need. Earlier versions of Acronis True Image needed the whole chain of differentials to run the validation task. Now if you select to validate one full backup archive, the archive will be validated. If you select to validate one differential backup archive, both the differential and full backup archives will be validated (leaving out the differentials in between selected one and the full one).

Finally, from the ATI 2010 User Guide - basic concepts section:

Backup file format

Acronis True Image Home saves backup data in the proprietary tib format using compression. This provides for reducing the storage space requirements, as well as for backward compatibility with the previous Acronis True Image Home version. While creating a tib file, the program calculates checksum values for data blocks and adds these values to the data being backed up. These checksum values allow verifying the backup data integrity. However, using the proprietary format means that the data from such backups can be recovered only with the help of Acronis True Image Home itself – either in Windows or in the recovery environment.

Backup archive validation

How can you be sure that you'll be able to recover your system if the need arises? The feature called backup validation provides a high degree of such assurance. As was already said, the program adds checksum values to the data blocks being backed up. During backup validation Acronis True Image Home opens the backup file, re-calculates the checksum values and compares those values with the stored ones. If all compared values match, the backup file is not corrupted and there is a high probability that the backup can be successfully used for data recovery. It is highly recommended to validate system partition backups after booting from the rescue media.

Note: the information above for 'Basic concepts' is given in the user guides for later versions of ATI upto 2015 thru 2020 when the file format detail is removed and the validation section is reduced to a minimum.

Backup validation (ATI 2020 User guide: Basic concepts)

The backup validation feature allows you to confirm that your data can be recovered. The program adds checksum values to the data blocks being backed up. During backup validation, Acronis True Image opens the backup file, recalculates the checksum values and compares those values with the stored ones. If all compared values match, the backup file is not corrupted.

 I think that I prefer the better honesty of the 2010 guide statement that says:

If all compared values match, the backup file is not corrupted and there is a high probability that the backup can be successfully used for data recovery.

This is more aligned with KB 1517: Troubleshooting Issues with Corrupt Backups - where the ways in which backup files can fail validation / become corrupted is described.

Kojote

Mit einem so großen Problem sollte nichts aus der Beta herauskommen. Jemand sollte unter seine Inkompetenz zurückgestuft werden. Ja, ich bin sehr verärgert.

In der Unternehmerkolumne kann man sich solche tibx-Einführungen nicht leisten.
Die Heimanwender sind großartig, wenn sie als erste die Fehler melden.

Ich kann mir nicht vorstellen, dass die Validierungsfehler und die Backup-Verlängerungszeiten von einem der Betatester von Ati nicht bemerkt wurden.

coyote wrote:

... I just got this morning from Pramod Tungal at Acronis:
...
I would like to inform you that tibx format for Acronis True Image 2020 exhibits this behavior by design. I am sorry, your experience did not meet your expectations.

Actually, I don't think this matches anybody's expectation - certainly none of the many people commenting on this forum. 

If Acronis has changed both the behavior and purpose of Validation then Acronis should make an effort to educate us on this behavior and purpose.  (Perhaps the purpose of Validation has not changed and we have just been using it inappropriately / unnecessarily all along.)

I am also having issues of extreme slowness with ATIH 2020. It has updated to 21400. It is currently piddling on a differential backup chain of a Drobo device connected via USB3 with about 1.5 TB on it. The backup time is showing > a day after running for almost that long. Backup progress is showing only 261.8 GB in that time. It seems as though it has to scan the entire volume to backup differentially. Naturally this puts a lot of unnecessary wear on the Drobo and its disk stack. This is on Win 10 1903.

I'm had a similar issue with a bare metal system restore of the boot nVMe SSD. Microsoft has decided for some reason to not show the 1909 update to my Dell XPS15 9570 even though Dell says that model has been tested and is compatible with 1909. I got stubborn and forced the update with an ISO. Everything was working fine except the search bar would no longer work. It would only accept 1-2 typed characters and stop and close with no results. I found out this has been an issue with earlier builds too, but not for me. I tried 4-5 published fixes to no avail. So I decided to restore to 1903 via ATIH. The good news is that the restore eventually completed successfully and the search bar problem is gone.

The bad news is that the restore took many hours. I booted to the recovery partition on the external USB 3 hard drive backup. Within the WinPE environment, EVERY single step seemed to lock the PC for 30-40 min, then I'd get the next screen. This took hours. Once the restore actually started, it only took 30-40 minutes. restore size was only around 160GB for all volumes on the startup disk.

I had better performance out of 2019 and am thinking of reverting back to it. I remember even better performance with TI before 2015. I used Mac from 2015 to early this year and used Time Machine instead.

ATIH 2020, in particular, has been an unpleasant experience for me. If you guys have any ideas, I'd love to have them.

Lloyd

@Steve Smith
Thank you so very much Steve; I honestly did believe you, and your memory was perfect.

It does sound no more than a checksum; but it seems to me a user can gain more assurance with a faster mounting operation!

Acronis really oughta pay you; I still haven't heard back with my separate inquiry to them whether it was more than a checksum operation.

@Logitech21
Good points (once google translated for me)!

/Break/
A couple days ago I started running w/o validation thanks to Steve's educating me.  It's been nice to have backups complete in the pre-2020 time (4% of the 2020 time).

I also mailed and faxed a letter to both the Acronis CEO in Singapore and the Acronis USA President.

I must say that ATI's backup functionality is by far the most robust I've used.  And in years of running validation nothing has ever failed.  But still...

I think the next time I create a backup specifically to test something after which I plan to restore, I'll run a Mount operation first right after the backup to gain something like the confidence I honestly think validation should have been giving us all along.  (I imagine that checking the runtime validation box could and should be doing something like running a test mount operation on the current backup, and checking the scheduled validation setting could and should do the same.)

coyote wrote:

I think the next time I create a backup specifically to test something after which I plan to restore, I'll run a Mount operation first right after the backup to gain something like the confidence I honestly think validation should have been giving us all along.

Wait. I see in the release notes for the update I installed today:

"Known issues and limitations of this version
Acronis True Image 2020 introduces a new technology for disk-level backup. The technology is still being improved, so you might encounter the following limitations:
TI-172340 The backup mounting option is not supported for the new backup format, *.tibx."

So I guess I'll need to do one of the other options Steve listed in the following sentence above:

"The only real test is to check the archive contents by exploring them, or mounting the archive, or recovering to another drive etc."

How does one "explore" an image?  Recovering TO ANOTHER HDD is a very good idea, thanks Steve.

How does one "explore" an image? 

The same as always by double-clicking on the .tib or .tibx file in Explorer to open it, then work through various folders etc randomly.

You might want to consider running a stand alone validation of the backup you wish to recover.  Validation of the new .tibx format from a performance stand point will vary dependent on the complexity of the backup file itself.  For example a backup file that is configured to not contain a lot of incremental pieces will run faster than a backup file that contains a lot of incremental pieces.

I am providing LINK below where I posted a response to another user about this subject that should be of benefit to you.

LINK

@Steve
Ah yes I see; I never tried that, I thought it would be the same as a Mount.

@Enchantech
Thank you very much for your reply, you're right I think I will do that before restores now that I've stopped Validating during backups now that Acronis effed up that by making it take forever.

But I do wish that validation did more than a checksum verification that it's intact.  Many of my restores are done immediately after creating the image (to test something, or try something) so I have no doubt they're intact from when completed two seconds before.

@coyote,

I understand your position.  Since you perform restores of backups at times immediately following backup creation might I suggest that you create one off tasks for such backups then when the backup completes run validation on it prior to recovery.  Once the validation completes and passes you can then recover the backup and when finished and satisfied with the results you can delete the one off task and backup file if you like or just delete the task itself and retain the file if needed or desired.

When True Image creates a backup or performs a recovery at the disk level these operations are done by block.  Blocks can contain one or more sectors.  The reason for performing disk operations at the block level is to increase performance.  The .tibx format, when backup of data is performed,  each block records checksum's of that block.  Validation is a method then of verifying that these checksum's are identical between the checksum recorded for each block when recorded and what exists on media to be recovered.  Performing such checks at the block level insures data integrity.  So for backups that you wish to retain, validation can insure that corruption has not been introduced between the time you created the backup and what exists currently on disk.  Keep in mind that ECC is used when writing and reading block data so the possibility of corruption existing is well, pretty much non-existent.

The key to all of this is to keep your backup tasks small in structure.  The fewer files that exist in a backup plan (task) the better the performance.  Users whom run incremental schemes need to reduce the total number of incremental files a task will produce to keep performance in check.

@Enchantech
"I suggest that you create one off tasks for such backups"

A good suggestion in terms of both backup restoral speed and reliability, so I sometimes would do this, if I suspected it was likely the restore would be needed after whatever I was gonna do next.

"verifying that these checksum's are identical between the checksum recorded for each block when recorded and what exists on media to be recovered"

Just to be clear (more clear I think), you're restating what I learned from Steve above that the checksum is compared only to the image (not to the source data [such as via a snapshot saved somehow] on the drive that got imaged).

coyote wrote:

Just to be clear (more clear I think), you're restating what I learned from Steve above that the checksum is compared only to the image (not to the source data [such as via a snapshot saved somehow] on the drive that got imaged).

@coyote,

No, not exactly.  Validation in prior versions of ATI before 2020 performed checksum validation on the backup image file itself to detect possible corruption to my understanding.

Validation as performed in ATI 2020, is a checksum calculation at the disk block level which is different  than that of a file itself.   A block level checksum is actually run on the partitions themselves so corruption can be reliably detected.

Some basics on partition structure may be in order here:

1. Data blocks, also called clusters, are the areas on disk where checksums are applied.
2. Various sizes of clusters - from 512 bytes up to 64 KBytes are supported on disks. 4K clusters are now considered the standard.
3. An partition is symbolically divided into two areas.  The first 12% of partitiion area are assigned to the MFT (Master File Table) and holds the MFT metafile.  This metafile grows as more and more file are added to the partition and contain information about each file such as the file location on disk.
4. On GPT formatted disks, a copy of the MFT is made on the last of the partition as a safety net against corruption of the MFT.

ATI backup procedures apply checksums to each data block across a partition.  Validation verifies these data block checksum values.  Values that do not match are deemed corrupted.  In addition to these checks an ATI disk/partition backup file contains the following:

A disk/partition backup contains all the data stored on the disk or partition:

1.Zero track of the hard disk with the master boot record (MBR) (applicable to MBR disk backups only).

2.One or more partitions, including

1. Boot code.
2. File system meta data, including service files, file allocation table (FAT), and partition boot record.
3. File system data, including operating system (system files, registry, drivers), user data and software applications.

3.System Reserved partition, if any.

4.EFI system partition, if any (applicable to GPT disk backups only).

So given the above a validation check run with the ATI 2020 version occurring on a block by block level across a disk is a sound way to detect corruption.  Therefore, validation now is a reliable method of assuring disk/data integrity.

Bob, in the ATI 2020 User Guide: Basic Concepts section, it has the following description of Validation which is consistent with that given in previous versions of ATI.

Backup validation

The backup validation feature allows you to confirm that your data can be recovered. The program adds checksum values to the data blocks being backed up. During backup validation, Acronis True Image opens the backup file, recalculates the checksum values and compares those values with the stored ones. If all compared values match, the backup file is not corrupted.

The key point above is the sentence that states clearly that "During backup validation, Acronis True Image opens the backup file, recalculates the checksum values and compares those values with the stored ones."

There is no validation of the source data from the original drive location as this will already have changed just with normal OS operation.

Steve,

I think the part you are missing is that 2020 now compiles a metadata database when a disk level backup is performed.  Additionally. a checksum is calculated for each block/cluster of the disk.  The metadata database contains these values.  When validation is run, the "During backup validation, Acronis True Image opens the backup file, recalculates the checksum values and compares those values with the stored ones." is what takes place.

Your contention is that this checksum verification will not insure that corruption does not exist in the backup file?

If yes then you do not agree with the statement in the quote above " If all compared values match, the backup file is not corrupted."?

Can you explain why you do not?

Bob, the validation process is only really able to confirm that the data in the backup files remains as it was when it was written to the file.  This should provide a reasonable indication that the data can be recovered but as the old adage goes: 'garbage in = garbage out'.  If there is any corruption already present in the source data then this is captured 'as is' in the backup archive.

With regards to the metadata file - just looking inside the new 12kb .tibx metadata file shows that this does not contain any additional block tracking information or checksum values - the majority of the file content shows as null values.

A new full disk backup has only one .tibx file which has to be totally independent of the original source data in order to allow validation by either the rescue media or on a different computer, so all the checksum data has to be self-contained.

The only real change that I perceive with ATI 2020 is the additional processing performed during the backup process to ensure the integrity of the data being written to the backup file (which users are complaining about because of the longer times needed now!).

Steve,

I get your point, there are only two surefire  ways to know if an image can be recovered, an actual restore to a disk or a restore to a VM.

If checksum done at the block level match during validation the probability of a successful recovery are very high.  Agreed this does not check all factors for recovery thus the surefire ways mentioned above.

My point is that validation as is now performed by TI 2020 increase the probability of successful recovery above that of previous versions.  A backup file saved in storage media can become corrupted.  Validation provides a way to check for such corruption.  Periodic validation runs are therefore worth doing.

As I see it the issue for users for the most part is how they go about setting up backup schemes. Most are way to data intensive and require not only excess time to process but large amounts of resources.

I copied from the User Guide what appears below.  I believe all users should have a read of this and decide if there backup scheme is the source of perceived poor performance or not.

Validation

An operation that checks whether you will be able to recover data from a particular backup version(p. 192).

When you select for validation...

• a full backup version(p. 193)-the program validates the full backup version only.
• a differential backup version(p. 192)-the program validates the initial full backup version and the selected differential backup version.
• an incremental backup version(p. 193)-the program validates the initial full backup version, the selected incremental backup version, and the whole chain (if any) of backup versions to the selected incremental backup version. If the chain contains one or more differential backup versions, the program validates (in addition to the initial full backup version and the selected incremental backup version) only the most recent differential backup version in the chain and all subsequent incremental backup versions (if any) between the differential backup version and the selected incremental backup version

The predominant scheme I see here in the Forums is Incremental.  I get the reasoning for using that scheme however, it is apparent that an incremental scheme implemented wrong will hurt performance.  I only suggest that users be mindful of the implications of the incremental scheme and when deciding to use it they know what to expect.

Validation as is performed now in TI 2020 along with the metadata compiled for each backup go a long way in improved reliability of the product.  That should translate into confidence in the backup itself. 

According to the text Bob pasted, Incremental Validation is supposed to validate the one chain, not all the chains like it appears to be doing (and turned out to be the original answer to this thread) and which Acronis is telling us with a straight face is by (ridiculous) design.

Oh and I'm assuming Bob means "implemented wrong" by the user.  (Which I think I avoid by running a new Full weekly.)  Or correct me if I'm wrong, maybe by ""implemented wrong" Bob means that the program was intentionally written in a way that somebody fully deserves to be demoted for. 

(I have as yet not heard back from my faxes to the Acronis CEO and Acronis US President; Support offered me a refund for which my license would have been revoked, and I didn't accept both because the ridiculous all-chain Validation already cost me enough extra electricity I think they owe me the refund, and if the CEO doesn't also deserve demotion he'll thank us for bringing this to his attention.

@coyote

I believe you are misinterpreting the text I copy/pasted from the User Guide.  An incremental scheme chain is all files created from and including the initial Full backup file, all .inc files after the initial Full until a new Full is created and even then, if automatic cleanup is not turned on the app will continue to add more backups to the chain.  In this case the chain goes on creating files for a time period that will eventually degrade performance to an unacceptable level for the user.

The default settings for an file/folder incremental scheme are daily, 1 Full followed by 6 incremental followed by another full and continuing for a time period of 31 days which will produce 31 files. 

The default settings for an disk/partition incremental scheme are weekly, 1 Full followed by 5 incremental followed by another Full and continuing for a time period of 183 days or 26 weeks producing 26 files.

Is this plan wrong?  Maybe, it all depends on the amount of data being backed up.  Some users have huge 4TB hard drives holding Windows and all user data that often exceeds a TB of data.  If such a user generates a lot more data on a weekly basis this scheme may not be a good fit for the user.  If on the other hand this user does not generate large amounts of data every week then this scheme may work fine for them.

Do I think your plan is a good fit?  Doesn't matter, do you think it is a good fit?  If yes then great. If no, then consider adjusting settings or even changing schemes to one that works for you, one that your happy with.

Do I think the program was intentionally written in such a way as to cause harm or get someone fired?  Not hardly!  I have always considered the default schemes to be starting points to build from, not something to just use as is.  I suspect there are a good many users that do just run the default out of the box schemes however.  

So when I say a backup plan was implemented wrong I fully mean by the user.  Do I think the way in which incremental backups are now handled wrong?  No I do not.  I think the handling is fine.  I think the users need to have a good understanding of how the application works so that a backup plan can be decided upon that will have good performance and meet the needs of the user.

@Enchantech

".inc files"

FWIW these must be in another ATI folder, they aren't in the folder with my .tibx file (which I thought was the single file for a whole chain now with 2020).

You go on a bit about scheduling backups, which I don't do (I launch my daily incrementals manually, my personal schedule does not make automating their launch convenient).

"the chain goes on creating files for a time period that will eventually degrade performance to an unacceptable level for the user"

In a quarter century of doing base/incremental backups I've never seen this because I wisely create a new Full weekly.  No noticable degredation with only a week of incrementals per chain.

Now, it seems you don't understand what people incuding me are identifying as the problem with ATI2020.  Until 2020, if one wanted to Validate a backup one could choose to, and it would only validate that one chain.  Now ATI2020 insists upon, and one cannot opt out of, validating all the chains on one's HDD.

Speaking of which, "huge 4TB hard drives" is nothing, I have a 12TB HDD solely dedicated to containing backups [for a HDD, incidentally, containing 1.2 TB of data].

So now, because of this idiotic change by Acronis, instead of daily Full/Incrementals that my PC completed conveniently overnight while I slept (but just barely), with ATI2020 I have something I want to run daily but can't because each run would take weeks (to validate 12TB of bloody chains).

(Why 12TB of chains?  The answer of course is that I'm a wise and careful and responsible backup practitioner.)

Now, if this change is not idiotic, you tell me how I can run something daily that takes weeks to run (not to mention ties up my computer resources throughout instead of only while I slept)?  Do you have some kind of enchantment that would allow my PC to freeze time in the universe so it could run a backup for weeks in the few hours I sleep?

Do you get now that forcing me to have all my chains validated if I only want the backup chain I'm creating validated is madness in that it is untennable?

This change was intentional, and whoever didn't realize it was idiotic needs to be demoted back below the level of their incompetence.

@coyote,

Actually you have confused your problem more now with all you have said. 

".inc files"

FWIW these must be in another ATI folder, they aren't in the folder with my .tibx file (which I thought was the single file for a whole chain now with 2020).

The .tibx format no longer shows .inc files as individual files.  Each incremental file created is merged into the initial Full file of an incremental scheme.  File naming has changed and no longer shows as in the past.  The Activity tab in the GUI will show you the incremental files of and incremental scheme.

In a quarter century of doing base/incremental backups I've never seen this because I wisely create a new Full weekly.  No noticable degredation with only a week of incrementals per chain.

How do you create the new Full each week?  Do you create a new task or do you simply change the existing task?  If you are just changing the existing task or you have the task setup to create a Full version every week then your backup chain is continual.  A new Full does not end the chain.  Cleanup will remove previous incremental files that are based on a Full but this does not change the fact that the backup continues to grow.

So now, because of this idiotic change by Acronis, instead of daily Full/Incrementals that my PC completed conveniently overnight while I slept (but just barely), with ATI2020 I have something I want to run daily but can't because each run would take weeks (to validate 12TB of bloody chains).

(Why 12TB of chains?  The answer of course is that I'm a wise and careful and responsible backup practitioner.)

I have no idea how you conclude the above. How do you calculate "(to validate 12TB of chains)?  Did you mean 12TB of chain?  If you did, 12TB of chain IS going to take week to validate yes. 

Now, if this change is not idiotic, you tell me how I can run something daily that takes weeks to run (not to mention ties up my computer resources throughout instead of only while I slept)?  Do you have some kind of enchantment that would allow my PC to freeze time in the universe so it could run a backup for weeks in the few hours I sleep?

If you wish to share your task settings so that your question can be addressed please do so.  Not knowing how you have things setup, no one can offer any advice.

Do you get now that forcing me to have all my chains validated if I only want the backup chain I'm creating validated is madness in that it is untennable?

 

The above only serves to affirm to me that you are not willing to approach your backup needs by embracing a different approach than what you have practiced in the past.

"Do you create a new task or do you simply change the existing task?"

I change the existing task.  Are you saying that Acronis was right to remove the option they removed and thus force me to create a new task every bloody week?

"Cleanup will remove"

Please stop lecturing me.  Cleanup does nothing for me because it is worthless for people who manually launch backups (changing launch times messes up the cleanup tracking).

Blah blah.  If they've defined all my weekly chains as one chain, that's idiotic too.

I imagine you're trying to help, but I've had enough thank you.  You're not responsive, you're not clear, you're not helpful, and over the years I've come to regard you as a bit of a nut.

p.s.  In case it is not clear why it would be wrong to say 

"Acronis was right to remove the option they removed and thus force me to create a new task every bloody week"

proper user interface design automates the user experience as much as possible, and that is orders of magnitude more true, the most true of all program types, for backup programs.  In other words, people won't back up if it's less automated that it should be.  So only a crazy person would intentionally force me to create a new task every week in order to use the program.

Though I do concede that it would be a good workaround (to address Acronis' mistake in not making all-chain validation an option instead of required if backup validation occurs during backup) to create a new Job for every Full.  And I thank Steve for having already suggested this workaround upthread.  And for educating me to instead not value validation enough to do it for now, since I don't think it's worth the trouble of creating a new Job for every Full.  (Why?  Well it's true that the image file can get corrupted, but it's not the only copy, it's a backup.)

Based on your reply I assume:

1. You cannot schedule your backup task so you run the task manually.
2. You use an incremental scheme that creates 1 Full followed by 6 incremental then repeat or
3. you create 1 Full and have set (Create only incremental versions after the initial full) and when the 6th Incremental runs you then change the task to create a new Full, then modify the task again to only incremental

So how about you try this:

1. Set the Schedule to Non-scheduled of course
2. Set the Backup scheme to Custom
3. Leave the Backup method as incremental and set the retention rules as (Create a full version after every 6 incremental versions
4. Store no more than 1 recent version chains

With this configuration your backup chain will never exceed 1 Full + 6 incremental files.  After the 6th incremental, the task will create a new Full backup file from the initial Full through and including the 6th incremental and then delete those files leaving only the new Full and will then repeat the incremental backups.

Your backup chain will now be a more manageable size even at its largest.  Performance should increase to more expected levels of what you're accustomed to, and validation should run at a much better pace when you do chose to run it plus, you can stop modifying the task each week.  All you will need to do is manually run the task each day as you currently do and decide when and if you run validation.

Ok.  That's pretty much what I already do, except for:

"4.  Store no more than 1 recent version chains"

Because this defeats an important purpose of why a wise backup practitioner like I am saves weekly-backup-chains going back as many months as fit on their HDD.  (For pretty much all the reasons one makes backups; to be able to restore deleted and corrupted files, recover from malware, etc.)

Or do you think that I should only have one week of backups I can fall back to instead of Acronis providing the option they took away because they were lazy/stupid?

I give you credit for remaining civil.  But at best here it seems like you're so set on defending what they did that you're willing to suggest I cripple my good backup practice before questioning why they took the option away I'm pissed about.

Let's just give up.  I think it's clear I know my options, and deserve some respect instead of more suggestions.  Until they reverse their error my practice will be to avoid the quicksand they've made runtime validation.

p.s.
I guess the "retention rules" you mention above is the automated cleanup I mentioned above doesn't work because as I noted above modifying the schedule messes up the program's ability to do it.

Alright, this will be my last post here to you unless you desire otherwise.

So you feel the need to have an entire 12TB hard drive full of backups for your safety net.  That's fine, here's a way to do that.  First, leave the Backup scheme set as Custom.  Under the Backup method, click on the colored text that says "Turn off automatic cleanup".  This will disable all cleanup rules.  Run the task to the point where the last incremental backup completes.  Now, turn off Active Protection in the TI GUI.  Next, using Explorer, create a new folder on your 12TB drive, lets call it Backup Archive for this example.  Now move all the files created by the task to Backup Archive folder.  After that and your ready to start backup again, run the task.  Repeat the above. 

Result should be that your task, for management purposes, remains at a smaller, manageable size at any given point in time.  This scenario will not break the task either.  It will continue to function in the manner described.

Edit:  After you move your files to the Archive folder on your 12TB drive, turn on Active Protection again.

Coyote, the process outlined above by Bob can be automated using the powershell script I wrote for forum topic: Full Backups no independent entity - for another user.  I still have this working on my own laptop as a Post Command for a test task.

@Steve
Wow, thank you very much for that!

Can I please ask a how often a user would run your powershell script?  (I'm guessing not just once [then never again], but for every time "the last incremental backup completes".)

I would absolutely use that--if my computer could even boot to the ATI2020 boot media (a separate issue I'm hoping to address in another thread).

@Enchantech
That Acronis' decision to not itself provide users with the option they took away, required Steve to write, and users to run, that powershell script in no way diminishes my conviction that at least one Acronis programmer and at least one Acronis manager made a serious error designing the ATI2020 implementation.

I'm appalled, both as a programmer and systems designer, and as someone who supervised a team of programmers.  

I imagine me banging this drum has been tedious for both you and Steve, and thank you for your kind indulgence.

@coyote

The script that Steve wrote is nice work, something that I believe he found compelled to write in response to another thread on this Forum.  He is very gracious for offering it to the users of TI.

Although I understand, at least to some degree, your requirements for backup, I do not share in your disdain for the product or those behind it.  Nevertheless, we are entitled to our respective position on that.  Personally, I like the new changes but then I have a completely different requirement in backup than you.

It is simply my hope that if you choose to try my suggestion it will fit your needs and return performance to a level that you expect.

Can I please ask a how often a user would run your powershell script?  (I'm guessing not just once [then never again], but for every time "the last incremental backup completes".)

I would absolutely use that--if my computer could even boot to the ATI2020 boot media (a separate issue I'm hoping to address in another thread).

The script (for me) is used in a Post Command and for a task that is only creating full backups, so it runs every time the task runs.  It would cause an incremental backup to keep creating the initial full backup file on each run, as the script moves the .tibx file to a second location, so it would never be present to add an incremental to!

Running any powershell script from Acronis boot media poses a very different challenge!
WinPE does not include Powershell support by default, so would have to be added to the rescue media.  I have done this but have never tested running a script as a Post or Pre command from rescue media.  A lot of the script would be redundant in the rescue media as AAP would not be active or present either.

@Enchantech
"I like the new changes but then I have a completely different requirement in backup than you"

That's fair.  If the change didn't affect me personally I'm sure I've leave it to others that it did affect to be upset by it.

@Steve
Thanks very much.  It would be fun to use your script, but I'm not really disappointed I can't since I'm enormously busy with a million things (and I'd have to google powershell script to even know what powershell is).

As a p.s. to my previous post, since my computer can't even boot to the ATI2020 media I'm using ATI2018 media to manually make all my backups. 

(Actually, my other computer can boot to ATI2020 media and I use it to make all my .tibx backups on that computer, and it does not demonstrate the same issues I'm complaining about, in other words it's backups with validation take the exact same time to run as did ATI2018 [both inside Windows and with 2018 boot media]!)

So it was tempting when Acronis support offered to refund my ATI2020 purchase to take them up on it, but that would mean revoking it's license and AAP2020 seems a vast improvement on AAP2018; infinitely smarter it seems!  (AAP2018 neither learned or provided clear feedback.)  And I had/have some hope that the Acronis CEO will not just respond to my letter but refund me without losing the license.

I've heard some good news in a very impressive reply to my letter from a member of Acronis' leadership.

First, I was impressed to hear that they became of aware of the issue not just because of Support cases, but also because they keep an eye on this Forum (good for them, I wish all companies did!).  And I respect that they are taking the issue seriously.

Here's an excerpt:

"...and as soon as concerns about this validation behavior were brought up in Support cases and on Forum, we’ve reported it as a potential design change to our Product team. 

I’ve checked with Product Management leader on current status of this change request => and currently several possible options are being reviewed.

I should have further news on specifics of these options in 1-2 weeks".

Thanks for posting. Very encouraging.

Yes Enchantech, it was encouraging!  ...But that was the last I heard.  (So it turns out I paid for ATI2020 only to use it for a year for nothing but the [much improved over ATI2018] AAP, since I've been backing up daily with the boot media.)

Looking at the documentation on the ATI2021 Beta, I'm not sure this issue has been addressed (and I don't have a spare system on which to run the Beta, so I can't figure it out myself).

I did see something about "Quick Validation"

in the ATI2021 Beta Guide

And I did look for elaboration in the ATI2021 Beta User Guide but not only could I find no elaboration, I couldn't even find the relevant screen I only saw in the Beta guide image displayed above.

Of course what I want to know is, can I choose between the old way (validating only the most recent chain) and the 2020 way (validating) all the chains.

On the new backup settings seen it looks like one can choose between validating:

1.  "the latest diverse backup version only" (does that mean only the last incremental backup file, or does it mean the whole most recent backup chain?), and

2.  "entire backup" (does that mean the most recent backup chain, or does it mean all the chains?).

Below on the image displayed above I see validation scheduling, but I don't really need to know what it's options mean since I don't want to schedule any validation.

delete please

@coyote, if your system has sufficient resources and you can be bothered with undertaking the task, you could try testing on a virtual machine such as VirtualBox or VMWare Player. There is thread (rather short) dealing with this possibility (see Running ATI in a virtual machine). Several of the beta testers have been using virtual machines in their testing.

Ian

Thank you very much for the reply, IanL-S!  My computer is 16-years old so I'm skeptical it could handle that.

p.s.  Oops I hit the Solution button on your post by mistake, and it seems like there's some bug that won't let me undo it.

coyote wrote:

Thank you very much for the reply, IanL-S!  My computer is 16-years old so I'm skeptical it could handle that.

p.s.  Oops I hit the Solution button on your post by mistake, and it seems like there's some bug that won't let me undo it.

Hi! Removed the mark  

I'm about to have a Windows OS for the first time in nearly a year.  I own ATI2020.

Can anyone please tell me whether it turned out that ATI2021 allows one to choose between the old way (validating only the most recent chain) and the 2020 way (validating) all the chains?

Either way I might wait for ATI2022 to upgrade.  Or go Steve's way and skip "validation".

ATI2021 does offer more choices about validation including just checking the latest chain instead of everything ever created!

Unfortunately, it also brings in Acronis Cyber Protection which is always active regardless of being turned off 'permanently' in the settings!  Finally, Acronis in their ??wisdom?? have decided that users cannot buy perpetual licenses anymore!

Hi Steve, many thanks once again!

That's great news that ATI2021 doesn't insist on validating every chain ever created.  (For people like me with vast archives of chains, that was nuts.)

Did subscription-only begin with ATI2021?

Oh no, from your wording I guess that "Acronis Cyber Protection" is not beloved.  (And just when I became happy with AAP on ATI2020!)  May I ask what main issue people have with "Acronis Cyber Protection"?

From my own look at
https://www.acronis.com/en-us/products/cyber-protect/
I'm very unhappy that this great backup software has become also an Antivirus that one can't turn off.  (I guess I have another thing to write to Acronis about now, sigh.)

It sounds like I might need to seek another solution.  While I'm liking Clonezilla on boot media on my Linux dinosaur, I really like the convenience of being able to schedule and run backups in Windows.