On 2015-05-20 10:10 AM, Dimitri Maziuk wrote:
> Then why TF are you quoting lto sustained write to hdd random i/o? "Disk
> subsystem can't keep up with modern tape" in the same way apples can't
> keep up with oranges. Compare optimized sustained writes to optimized
> sustained writes or random seek time to random seek time or stop
> spreading fud.

I really don't know what point you think you are making.

What do you call it when multiple backup jobs are writing to disk 
storage while at the same time a copy job is reading from that same disk 
subsystem and writing to tape?  True we're talking about multiple 
'sequential' streams at the same time rather than pure random I/O, but 
for all intents and purposes that behaves as random I/O since you've now 
got seeks involved. You will be hard pressed to sustain more than 30-40 
MB/sec with even just 2-3 streams running on a single consumer hard 
drive.  More streams (concurrent backup jobs) will reduce throughput 
further.  This isn't FUD, this is REALITY.

If you want to keep a modern tape drive writing at its full speed you 
need a disk subsystem that is fast enough to supply that tape drive.  If 
you want to run multiple backup jobs to your spool device while writing 
to tape at the same time you need a decently fast disk subsystem that 
can keep up.  When designing a backup system you need to keep these 
things in mind.

Bryn



------------------------------------------------------------------------------
One dashboard for servers and applications across Physical-Virtual-Cloud 
Widest out-of-the-box monitoring support with 50+ applications
Performance metrics, stats and reports that give you Actionable Insights
Deep dive visibility with transaction tracing using APM Insight.
http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
_______________________________________________
Bacula-users mailing list
Bacula-users AT lists.sourceforge DOT net
https://lists.sourceforge.net/lists/listinfo/bacula-users