Your stated Force Rescan When condition ("Destination <> C:\") will presumably always be True? If so, it will always trigger (every run). If so, you are wasting your time / gaining no benefit whatsoever from using Fast Backup, because a Rescan discards any database which currently exists (probably created last run), and scans both sides again to build another. Tomorrow, same thing (it always scans - ad infinitum)*
If you want to achieve a situation where you (eventually) have seven full-backup folders whereby it doesn't need to scan the disk to find out the content of a particular day-folder (because it keeps seven FB databases, one for each day), then you could do it
with a single backup disk. There are details in the Help, but I won't go into it in detail here
because you are also rotating the drives, so that relying on a database-per-day-folder to tell it what each day-folder's contents were last time that day-folder was addressed is highly dangerous if you also rotate the drives. Why? Because if you keep swapping the drives over, the database of content it recorded at the end of the run for (say) day/folder-5 last week (using, say, drive-X) will almost certainly not be an accurate snapshot of the data in folder /5/ on drive-Y on day-5 this week (because that drive wasn't present on day-5 last week - the other drive was). Content will be likely be different, but the profile won't know that; gaps will start to appear...
You could also do it by using removable media x 14 (Mon-Sun x 2 weeks) providing you have a drive that accepts such media
and its drive-letter is static (always the same, so you can specify it 'in clear'). This works by generating 14 separate Fast Backup databases (!) where the profile figures out which one to use on any given occasion from (its stored key based on) the Destination path-of-the-day, which would incorporate the drive-letter, a (sub)folder based on the %DISKSERIAL% and a subfolder based on %DAYOFWEEK% (plus any static text). But you can't (shouldn't) do that with rotated USB drives because you can't achieve a guaranteed static drive letter (for the same reason you're using %LABEL=Backup Disc% now).
If I were you, I would simply switch off Fast Backup altogether, and just put up with the scanning (at 1 AM it's unlikely to get in the way of anything?). That way, SB will find out for itself what the content of the (current) Destination is (by scanning it), and make appropriate decisions based on true info (and not on info that might represent what was on the other disk same-day-last-week).
Re the 'number' question (3 v 7), there's no built in cycling Variable that spans 3 days. You could write an installable script to generate a custom Variable, but which rules you would use to define what value it has on any given day I'm not sure. Or, you could arrange for it to cycle 1 > 2 > 3 > 1 > 2 > 3... each time it runs (thus, independent of the day of week), but you'd need to make sure you only ever run the profile 'as per' the usage that logic you use expects (don't run it twice in succession on a given day because disk was powered off on first attempt, for example)
* If your profile will
always Rescan based on the When setting (yes - see above), it will also
ignore the 'Delete all on Destination.....
only if not a Rescan' setting (because
it always will be a Rescan). This is actually quite lucky, because the 'Delete all....if not a rescan' setting is there for housekeeping of
Differential and/or Incremental backups only (which are the only examples in the Help that use it, if you check). Using it when you want a full backup each day will actually result in the current day-folder first being wiped, but then likely only being repopulated thereafter by files that have changed on Source since the last relevant database was created. Files that haven't changed for months may be lost because the database - if there hadn't just been a Rescan - would tell Pro those unchanged files were still there. So it's quite lucky that right now it will never trigger...you should only ever use this for true Incremental or Differential backups, never for full backups
Statistics: Posted by cliffhanger — Fri May 20, 2016 1:25 pm