Configuring my new PC with ATI2020. Some questions

For your first point reference copying your incremental backup files using rsync.

Incremental backups of Disks & Partitions on ATI 2020 no longer create separate smaller incremental files, but are all stored within a single backup file along with the initial full backup for the chain. 

See the following KB documents published by Acronis with regards to .tibx files.

KB 63518: Acronis True Image 2020: do not delete first tibx file

KB 63227: Acronis True Image: Do not delete .TIB or .TIBX files outside of Acronis True Image

KB 63498: Acronis True Image 2020: new tibx backup format FAQ

KB 63425: Acronis True Image 2020: Limitations of tibx backups

KB 63516: Acronis True Image 2020: Incremental backups do not create separate files when using new backup format

KB 63445: Acronis True Image 2020: how to view and manage backup versions in new backup format

KB 63444: Acronis True Image 2020: tibx backups in local destinations

KB 63613: Acronis True Image: local backups are not available for recovery if "metadata" file appears in the backup destination - if you see metadata file(s).

Your options for the scenario you have described are as follows:

1. Switch from creating to making Differential files which do create separate files still but which will progressively grow in size over the period of a month as each new differential contains all changes since the initial full backup was created for the chain.

   or
    

2. See forum topic: How to create a Disk backup as .tib (not .tibx) which will create a new backup task using the older .tib format in the Windows ATI 2020 GUI.

For your second point about moving .tibx files, this is speaking about incomplete chains that would occur if not all associated .tibx files have been moved or copied to the second location.

There are greater dependencies with the new .tibx files than there were with earlier versions of ATI along with the change in naming conventions which makes it more difficult to identify the files belonging to dependent chains

Provided all dependent files are present, i.e. the contents of the default backup destination are mirrored to your second location, then there should be no issues with using those files should they be needed for recovery.

bushmaster,

Like you I found incremental files in the .tibx format to be unworkable for my uses.  I therefore switched to using the Differential Method.

I began with a default setting for a differential Scheme.  That scheme runs an initial Full disk followed by 5 differential files Daily then repeats over a 6 month period.  I started that task on Nov. 28th of 2019 using a data source of user data totaling 39.4GB which compressed to 12.6GB.  Over the course of the last 4 months the disk space required for the task grew to over 300GB.

As of 03/27/2020 I ran a Manual cleanup of the folder containing the task backup files it now totals 13.5GB and consist of the original Full backup that now is 12KB followed by differential 0120.tibx which totals 12.8GB compressed then two more differentials 0121 and 0122 of 348MB and 379MB respectively totaling 13.5 GB.

I have changed the Backup scheme to a Custom Scheme - Differential Method - Create a Full version after every 30 differential versions - Automatic cleanup is set to Store no more than 1 recent version chains.

The result here for this task will be 28 more differential versions followed by a Full version then cleanup of all old differentials and repeat.

My point is that if you use cleanup in your plan you can arrive at a Method that works for you.  If you choose to do manual cleanup and then rsync the end results to other locations that would result in fully recoverable files at these locations as long as all files of the task are in each location.

As a matter of good practice I do the majority of my restores using the bootable recovery media.  As a consequence, I create uniquely named folders whose name are descriptive of the data source.  Further, I use the same idea when naming a backup task in the TI application.  So when and if restoration is required it is easy to find the right location and the right backup file.

Hope this helps in your decision.

Enchant,

Actually, that helped a lot of us !  Thank you and Steve S. for the analysis.

You guys are why this forum is so helpful.

Now if Acronis will just get a few things fixed and get us an update 3 we may all start smiling again.

Thanks !

Steve F.

Bushmaster wrote:

<SNIP>

I see a problem as the incremental backups are merged to the first (full) backup. In other words: The file will change (probably even get bigger) with every incremental backup and the rsync will send the complete backup each night. 

<SNIP>

rsync only sends changed blocks by default. Thus it would only send the changed blocks that TI 2020 merged into the .tibx file, not the entire file. After a quick Google search I came up with this explanation that explains it in more detail:

http://tutorials.jenkov.com/rsync/overview.html

Depending on the NAS you are using, there might be a man page for rsync that will describe all the available switches and some usage examples.

Hope this helps.

rsync only sends changed blocks by default. Thus it would only send the changed blocks that TI 2020 merged into the .tibx file, not the entire file.

I can confirm the above after doing some testing with my Synology NAS after enabling rsync.

I used rsync to copy a full .tibx file across to the NAS, then made an incremental backup which updated the source .tibx, then ran rsync again which only copied the changed blocks, though did seem to take quite a while to compare for changes.

Windows Subsystem for Linux (WSL) needed to be enabled to use rsync on Windows 10, plus other settings changes were needed on the NAS.

The output from rsync showed the following:

smiths@StevePC:~$ rsync -av /mnt/e/Backup acronis@192.168.0.2::Backup/'HP Steve'/
Password:
sending incremental file list
Temp/Win 10 Full - Copy.tibx

sent 42,518,571,916 bytes  received 38 bytes  15,171,658.15 bytes/sec
total size is 42,508,193,792  speedup is 1.00

smiths@StevePC:~$ rsync -av /mnt/e/Backup acronis@192.168.0.2::Backup/'HP Steve'/
Password:
sending incremental file list
Temp/Win 10 Full - Copy.tibx

sent 1,655,596,505 bytes  received 2,597,067 bytes  647,099.93 bytes/sec
total size is 44,165,001,216  speedup is 26.63

Steve Smith wrote:

rsync only sends changed blocks by default. Thus it would only send the changed blocks that TI 2020 merged into the .tibx file, not the entire file.

I can confirm the above after doing some testing with my Synology NAS after enabling rsync.

<SNIP>

Of course that is the way it works; it's rsync's raison d'être. To force a copy of whole files you give it the -W switch.

Of course that is the way it works; it's rsync's raison d'être. To force a copy of whole files you give it the -W switch.

Having never used rsync, as most Windows users will not either, it is good to discover a tool that can do a delta copy of file contents instead of doing a full file transfer every time.

This has been a learning exercise for me to play with WSL, rsync and to get this working in a Powershell script that I can now use to run from the Windows Task Scheduler to keep some of my Incremental .tibx backups sync'd with my Synology NAS.  Much nicer to just copy a few 100's of MB's for an Incremental than the whole 60+ GB single .tibx.  In essence, this is much closer to how backups to the Acronis Cloud work but a pity that the new Replica feature doesn't adopt the same approach and allow using local destinations instead of just the Cloud.

Steve Smith wrote:

<SNIP>

 In essence, this is much closer to how backups to the Acronis Cloud work but a pity that the new Replica feature doesn't adopt the same approach and allow using local destinations instead of just the Cloud.

I agree; but then it wouldn't generate revenue by forcing people to use Acronis' cloud service, now would it?