Calculate rate of changed data

As an asdide, note that 100MB/min is far below the minimum speed for tape streaming with LTO 3, so you're probably losing a fair amount of capacity with the tape stopping and starting (ie you're probably getting better than 1.5:1 compression, but this is lost in gaps in the data on the tape). This will probably be rather worse with LTO 4, as I think the minimum speed has gone up.

Disk - Disk - Tape will help with the minimum speed problem, and will give you some capacity for free.

If you're not doing it, strongly consider some kind of scheduled defrag of the disks on the servers you're backing up. 1000 MB/min is not a great level of throughput for gig ethernet on reasonably modern hardware. I'd expect that on even 2 year old machines you should be able to get 1800MB/min (that's only reading from the server disk at 30MB/sec), so there's scope for improvement.

Edit: For LTO 3, you really want a 256KB block size for best performance.

WRT shoe shining, There's no time for the tape to rewind if the buffer runs empty briefly, so it'll leave a gap on the tape.

You don't specify what filesystem the NAS is actually running, so this advice is assuming you're running NTFS.

When creating a backup-to-disk directory structure the following are a good idea:

• The block-size the volume was formatted with should be large. NTFS defaults to 4K which is way too small. 64K would be entirely appropriate for a B2D volume.
  • Block/logical-sector alignment can improve performance, though you may not feel up to futzing with this.
• If possible, arrange things so only one volume is being written to at any given time. This increases the sequentialness of your backup files in the filesystem, and thus improves performance.
• If using NTFS, massive files (100GB) are harder on the OS than lots of smaller (10G) files are.

When we were still with 10D it did seem that BackupExec re-used existing backup-files in preference to spinning up new ones. This is fairly smart in that once a file is laid down, if it was done in one segment it'll stay that way so the volume won't fragment nearly as much as delete/recreate would. It depends on your storage, but usually keeping those files contiguous will noticeably improve your read/write performance.

For append/protection periods, it is my understanding that the Append period starts the moment the media is written to the first time and the Protect period resets every time it is written to. So if a file is written to on 1/5 with a 7 day append period and a 14 day protection period, the append period will end on 1/12 but the overwrite-protection period may not end until 1/26.

Variability in how fast your backups run will cause media to stagger their protection periods. If a backup stalls over a weekend and resumes Monday after you kick things, that media will come overwriteable 2 days later than normal and that can cause you problems later on down the road. Plan for extra space in your B2D archives for this kind of thing.