Backups keep failing most of the time.

We need more information about your backup script (retention and cleanup rules configured) - screenshots would be really helpful.  My guess is your backup chain is over and the next new full is needed based on your backup script.  You must always have a full at the beginning of ANY backup chain type (full, incremental or differential).  The full is the base of the backup and subsequent backups in an incremental chain would then be incremental.  If you made a full and then modified the chain retention to something less than the orginial, then a full is likely to occur and will continue with an incremental after that.

Keep in mind that your retention scheme should accomodate the amount of free space on your NAS.  It sounds like your NAS is running out disk space and can't handle this next full.  Automated cleanup will help with space, but Acronis will always make the NEXT ENTIRE FULL before deleting an older backup chain automatically so plan for that extra space too.  

Another possibility is you  have disk corruption (bad sectors) which may be forcing Acronis to try a sector-by-sector full backup, despite your backup script rules.  If need be, run chkdsk /R on the source drive, but wait until we know more about your backup task script.

Thanks for that and sorry about late reply.

I have attached the options selected for this backup and you can see that no full backup was asked for after the initial one.  In the bottom part of the attachment, you can see the backups to the NAS that have been made, i.e. the full one on 28 Feb and daily increments after that until the failed (full) ones - as seen in the attachment in my first post -  on 7, 10, 12 and 13 March.

There is no issue with space on the NAS with 2.34Tb free of 2.68Tb in total.

Ok, yes, I see what you mean since you now have "create only incrementals" listed now with no cleanup options enabled, yet it has made multiple attempts to create a new full in the past few days. 

Did you change this in the backup task recently where it did used to have fulls, but are now using this new backup scheme?  If so, it is wanting to start a new full to accommodate the change in the script.  I'm not sure how much free space you have on your NAS - can you check that too?  

Otherwise, the script appears to be corrupted and you should "clone" it and start with a new one (modify the name slightly too so it's not exactly the same!), re-pick the source and destination and start the backup again.  Do make sure you have the space to accommodate the new full backup when it starts and once backed up, if need be, delete the existing backup script and backup files associated with it to free up the space again.

FYI, I would not use this scheme with incremental's forever - not in any backup product.  Incrementals need all versions before them to be available and "working".  The longer you let the chain grow without a full, the more liklihood of some type of backup corruption (not just in Acronis, but again, any backup product).  If you're doing an incremental backup every other day, The most I would personally go is one month before a new full.  That way you have a new full starting point that should have no possibility of corruption due to multiple files needing to be pieced together to recover from, at least, not until close to the end of the month, but that is a reasonable time frame in most situations.

If you want to try and figure out more about why this behavior is happening, download the MVP logviewer and check the log for clues about what's going on.  

Iain, the image confirms your backup scheme and the files created so far but we would need to see the log file for the task where it wanted to create a new Full backup image to try to understand why it did so?

OK guys, here is the log from a failed day. what does it tell us?  Says teminated by user but that's not the case:

12/03/2019 03:06:37: +00:00 39952 I00000000: -----
12/03/2019 03:06:37: +00:00 39952 I00000000: ATI Demon started. Version: 23.4.1.14690.
12/03/2019 03:06:37: +00:00 39952 I00640000: Backup reserve copy attributes: format tib; need_reserve_backup_copy false;
12/03/2019 03:06:37: +00:00 39952 I00640002: Operation Iain Folders Backup started by schedule.
12/03/2019 03:06:39: +00:00 39952 I00640000: Backup reserve copy attributes: format tib; need_reserve_backup_copy false;
12/03/2019 03:06:39: +00:00 39952 I013C0000: Operation: Backup
12/03/2019 03:06:39: +00:00 39952 I0064000B: Priority changed to Low.
12/03/2019 03:06:50: +00:00 39952 I000B03F0: Create Backup Archive From: C:\Users\Iain\
C:\Program Files (x86)\Steam\userdata\
D:\Iain User Folders\Downloads\
D:\Iain User Folders\Music\
D:\Iain User Folders\Pictures\
D:\Iain User Folders\Videos\
To file: Iain Folders Backup_inc_b1_s10_v1.tib Compression: Normal Exclude: System files, Files matching mask Match criterion: hiberfil.sys, pagefile.sys, $Recycle.Bin, swapfile.sys, System Volume Information, *.tib, *.tib.metadata, *.~, *.tmp, C:\Users\Iain\AppData\Local\Temp, C:\Users\OVRLibraryService\AppData\Local\Temp, C:\Users\OVRLibraryService\AppData\Local\Microsoft\Windows\INetCache, C:\Users\Iain\AppData\Local\Mozilla\Firefox\Profiles\*\cache2, C:\Users\Iain\AppData\Local\Mozilla\Firefox\Profiles\*\OfflineCache, C:\Users\Iain\AppData\Local\Opera Software\Opera Stable\Cache, C:\Users\Iain\AppData\Local\Opera Software\Opera Stable\Media Cache, C:\Users\Iain\AppData\Local\Google\Chrome\User Data\Default\Cache, C:\Users\OVRLibraryService\AppData\Local\Mozilla\Firefox\Profiles\*\cache2, C:\Users\OVRLibraryService\AppData\Local\Mozilla\Firefox\Profiles\*\OfflineCache, C:\Users\OVRLibraryService\AppData\Local\Opera Software\Opera Stable\Cache, C:\Users\OVRLibraryService\AppData\Local\Opera Software\Opera Stable\Media Cache, C:\Users\OVRLibraryService\AppData\Local\Google\Chrome\User Data\Default\Cache, C:\WINDOWS\CSC
12/03/2019 03:08:16: +00:00 39952 I00040001: Error 0x40001: Error occurred while reading the file.
| trace level: information
| line: 0x1d8eab676a3f6921
| file: c:\bs_hudson\workspace\646\products\imager\archive\impl\operations\archive_message_callback.cpp:760
| function: TrueImage::Archive::ArchiveMsgReadCallbackProcessor::ProcessReadCallback
| line: 0x1d8eab676a3f6921, c:\bs_hudson\workspace\646\products\imager\archive\impl\operations\archive_message_callback.cpp:760, TrueImage::Archive::ArchiveMsgReadCallbackProcessor::ProcessReadCallback
| Path:
| $module: ti_demon_vs_14690
|
| error 0x40001: Error occurred while reading the file.
| line: 0x7ceb2cdc9fb1203c
| file: c:\bs_hudson\workspace\646\core\file\windows\win32_file.cpp:147
| function: win32_file::Read
| line: 0x7ceb2cdc9fb1203c, c:\bs_hudson\workspace\646\core\file\windows\win32_file.cpp:147, win32_file::Read
| function: ReadFile
| $module: ti_demon_vs_14690
|
| error 0xfff0: An unexpected network error occurred
| line: 0xbd28fdbd64edb8f1
| file: c:\bs_hudson\workspace\646\core\common\error.cpp:307
| function: Common::Error::AddWindowsError
| line: 0xbd28fdbd64edb8f1, c:\bs_hudson\workspace\646\core\common\error.cpp:307, Common::Error::AddWindowsError
| code: 0x8007003b
| $module: ti_demon_vs_14690
12/03/2019 03:18:17: +00:00 39952 W013C0001: Terminated by user.

Start: 12/03/2019 03:06:37
Stop: 12/03/2019 03:18:17
Total Time: 00:11:40

| error 0xfff0: An unexpected network error occurred
| line: 0xbd28fdbd64edb8f1
| file: c:\bs_hudson\workspace\646\core\common\error.cpp:307

Looks like the network may be dropping - is the NAS using power saving and possibly not being available when the backup starts up.  It also looks like it's having an issue backing up something in the C:\bs_hudson\workspace\646\core\common folder.  

Might want to run chkdsk to make sure there are no issues on the source drive.  If all is well, possibly exclude that folder.

Iain, the log shows the following key points:

12/03/2019 03:06:50: +00:00 39952 I000B03F0: Create Backup Archive From: ...
To file: Iain Folders Backup_inc_b1_s10_v1.tib
12/03/2019 03:08:16: +00:00 39952 I00040001: Error 0x40001: Error occurred while reading the file.

This shows it was trying to follow the incremental scheme in creating file b1_s10 (shown in your file listing with date 14/03/2019) but hit an error when reading back from the NAS.

Rob, the reference to C:\bs_hudson\workspace\646\core\common folder.   in the logs is quite common and comes from Acronis, not a user folder.

Guys, I discovered on my NAS log that there were bad sectors detected on one of the RAID drives. I've removed this and I'll monitor the situation for a few days.

Thanks a lot.

Thanks for the update Iain, hope the drive issue resolves this topic fully for you.