CPHO changing backup locations on its own, etc. DANGEROUS BEHAVIOUR!!
Why does the product scan for and either add new backup jobs or changes the location from tib/tibx files it finds?
Why is it even scanning for files on drives/folders it has ABSOLUTELY NO REASON OR NEED TO??
e.g.
I place all my backups in nested folders inside S:\Acronis Backups and NO WHERE ELSE.
I weekly make manual mirror copies (robocopy) of the backups of the S:\Acronis Backups folder to T:\Acronis Backups.
CPHO will at random on finding these files on T: (AGAIN WHY THE HELL IS IT LOOKING THERE?) either create a random backup job with the full name of a random backup it finds on T: OR change the location of the existing folder for the backup from S:\Acronis Backups to T:\Acronis Backups.
If I don't notice the drive change WHICH CPHO IS DOING WITHOUT WARNING OR REASON and run the robocopy job I end up losing backups as the newer backups on T: (WHICH SHOULD BE ON S:) get deleted/overwritten instead of all newer backups on S: being copied to T:!
CPHO HAS NO REASON TO BE SCANNING FILES NOT IN BACKUP JOB FOLDERS AT ALL, NEVERMIND CHANGING THE LOCATION OF EXISTING BACKUP JOBS AT RANDOM!!
WHY IS IT DOING THIS IS EXTREMELY DANGEROUS BEHAVIOUR AND HOW TO STOP IT?
The T: drive is a removable drive and CPHO still picks up the files at random. No backup jobs point to anywhere else but S: (except when CPHO thinks it knows better and changes it) this is what I mean by "no where else".
Usually T: is connected only when making the mirrors, sometimes this is for only 20 minutes, sometimes for 6+ hours, however long CPHO will for no reason at all pick up the files.
Everytime I connect the T: drive I feel like I'm playing russian roulette with the integrity of both the original backups and the mirror. Backups are meant to be a safeguard and relieve anxiety of data safety, not make make it worse and make me wonder that if I have to use them "are they reliable and can I reliably recover data using them?".
As for using CPHO to make second backup jobs, using the in built "reserve copy" is both slow and wasteful of space and requires manual pruning as all the second files are FULL backups and never deleted automatically. Plus reserve copies are only available on file backups and not image backup (I have a mixture of both). Also the automatic scanning pickups on the reserve files and creates multiple useless backup jobs of each reserve backup!
Create a second job then? Well its better than the reserve copies but still slower than using robocopy to mirror the backups and I prefer to the PC running 2x the current backup jobs all day. :(
The scanning raises concern over data privacy in some respects, after all its not just crawling though directories, its actively opening backup files and at the very least reading meta data from the backups. Who knows where this aquired data is being stored or sent to!
The only other suggestion would be to register to take part in the current ACPHO Beta testing programme for the 2023 version where you will be able to communicate your concerns over how it scans for existing backup archive files and try to request a method of controlling this.
One further late thought!
If you rename the file extension for your mirrored copy files on your T: drive, that would definitely resolve this issue as Acronis would not see any valid files on that drive, i.e. change .tibx to .~tibx during the copy.
I have used this approach previously to make single stand-alone full backup files (doing the rename via a post command script).
Powershell script to copy & rename extension:
# CopyRenTibx.ps1
# Set-ExecutionPolicy -ExecutionPolicy RemoteSigned
$SourceFile = "S:\Acronis Backups\*.tibx"
$Dest = "T:\Acronis Backups"
Get-ChildItem $SourceFile | Foreach {Copy-item $_ "$Dest\$($_.Name -replace ".tibx", ".~tibx")" -Force}I tested this against a folder with some of my own backups and it worked fine.
Note: Active Protection was turned off to allow to run, and if you haven't used Powershell before, then you will need to issue the command.
Set-ExecutionPolicy -ExecutionPolicy RemoteSigned
then answer the challenge to allow scripts to be run as are prohibited by default.
The script could be changed to rename .~tibx files back as .tibx in the event of needing same for a recovery etc.