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@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users
