jpl----
No it doesn't 'stop' me from going ahead with a backup attempt despite me
having to so do against a red line warning! Ten hours ago I set the thing
off... I gave it a single hour's window to see what happened. There is
nothing at all on the target/destination share. My CPU util has been showing
circa 95% for a dar process continuously. My OS drive array had some
50 or 60GB space on it originally. 'Something' has filled this up and now
there is about 2GB remaining. Presumably the backup run is now using
my (small) OS drive array to aggregate the backup run for a 2TB (data)
drive array... so I can see why I was given a red line text warning initially.
No, the backup run does not use your OS drive to aggregate anything.
Explication may be more trivial : share is not mounted and the backup was correctly running and saving datas on the server itself... 50 or 60 Gb of compressed data saved in 10 hours seems a normal value for that.
The questions in this case are : why was the share not correctly mounted, and why backup script does not detect it ?
Another point : how workstation dar backup will do to backup 2Tb of datas ?
In theory, it can do it, but not in one night through lan share. You must try to use one set of backup and incremental backup for a lot of days...
The first night the first backup will be stopped by the timeout you set (value is in seconds, not in hours). Not Terabytes of datas will be saved, just tens of Gb. The backup should restart and continue on next nights... until all datas are saved. It's possible only if the daily amount of changed datas is inferior to the amount of datas saved every night.
I think you understand we have not make tests for such amount of datas. But if it works it's a promising test