Doesn't the Minion solution only use one job? So you can't run 2+ backup jobs at the same time? And by default, it doesn't run log backups while the full is running?
Yes, that sounds right. Can't think of two backups I would want to run at once (except LOG + FULL as you say), but perhaps you would prefer to schedule all backups concurrently (so a long run LOG backup on one DB cannot hold up a LOG backup on another)? As it happens we don't do that to try to have one database log backup (and the sequential writes to disk which it entails) finish before another one starts, because I assume on our non-Stellar!! hardware that is better, but I'm aware of the limitation of a long running backup.
Thanks. That was the script that I looked at, I didn't look closely enough to see that it would do that. That's my gripe with it, really, the DOCs give no clue as to what one (i.e. a naive user) should do. If it is "just run this script" with a "make sure you CONFIG these few variables first" I think it should say that ...
... perhaps Naive Users will just run that script and all will be well !! but I wanted a bit more hand-holding / explanation in the DOCs. I'm sure I haven't read the DOCs carefully, but I have seen nothing that says describes what the default schedule is (in terms of how often FULL, DIFF and TLOG will happen)
1 Like
If your hardware can support it, no reason not to have two or more full backups running at the same time. Or maybe you want to kick off the index rebuilds on one database while another database is getting a full backup. If you've got big hardware that is not under pressure, let it do more work.
No problem with that 
I doubt we have that sort of hardware. My Drive for backups was chosen / optimised for sequential writes. Presumably if I do two backups at once then the disk heads will be dancing back and forth between the two jobs - which will spoil the performance. But that's just theoretical, I haven't tested it ... and as time passes I am more likely to be able to afford hardware where such thoughts don't matter.
I can remember with Floppy Disks we changed the sector skewing to optimise writing. The drive wrote a sector and then needed some time to assemble the data for the next sector, and the skewing factor meant that that sector would be arriving at the head just as all the calculations and data shuffling had completed ... that's something else I don't have to worry about any more!
1 Like
Thanks Kristen & Tara for your thoughtful discussions and insights!
Ball in in my court to implement the maintenance solutions. 