Alan thanks, I omitted that we have a Spectra LTO6 library which would be SAS
attached to the server in question but I didn't mention it as my initial query
was more about the hardware specs.
The rough plan would be D2D2T and we'd probably run one of our fileservers
(linux) directly to a local directly attached small LTO6/7 library as it's not
data where we need a long retention and it feels dumb to be running it over the
network just to send it to tape to keep for a week.
The hardware we have happens to have an 800GB SSD in it by a lucky coincidence,
which I thought could be used for the Postgres database (not used Bacula enough
to know how big the database may grow) which I image would benefit from it
immensely but I'm not clear what the "spool" is that you're referring to - a
quick dig suggests it could be attribute spooling or a spool area for data
that's going to tape?
Sounds like we're good on the hardware but if necessary throw in some RAM.
We're so new to Bacula that I'll be blunt and admit there's lots I simply
haven't got my head around yet if we do go with it so apologies if some of this
is dumb/obvious to most of you :)
-------- Original Message --------
Subject: Re: [Bacula-users] Hardware Specs & Sizing for Bacula?
Local Time: February 19, 2016 6:58 pm
UTC Time: February 19, 2016 6:58 PM
From: a...@mssl.ucl.ac.uk
To: paul.hutchi...@protonmail.com,bacula-users@lists.sourceforge.net
On 19/02/16 18:12, paul.hutchings wrote:
We're new to Bacula and are still considering if it's viable for us. Our test
environment is quite small (it is a test environment) and when I read the docs
I'm not sure how recent they are when they relate to hardware specs. For
example if I were to suggest box with dual 8 core E5 CPUs, hardware PERC RAID
card with 1GB cache, 48TB of 7.2k SATA in RAID6 and 32GB (or more) of RAM
running as a SD would people be thinking "hmmm may need more horsepower" or
would people be thinking "that should handle hundred/thousands of clients"?
It depends. For SD-only use, your CPU is overkill and even 16Gb of ram would be
overkill
Ram requirements are for the director and database. These can be on the same
box and probably should be to avoid networking penalties. You don't need VMs -
and really shouldn't play that game on backup-dedicated hardware as VMs come
with performance penalties ranging from noticeable to major.
Even with the DB and DIR on the box, your CPUs are more than adequate.
Assuming SD + DIR + Postgres (don't mess with Mysql for million+file
installations, it doesn't scale well) then, I'd add more ram. It's cheap enough
these days that you should think about running at least 96GB if you're backing
up tens of TB and tens of millions of files (even more if you can afford it)
The real issue if you're running backups at this scale: Disk is a liability.
It's too slow and drives will end up shaking themselves to pieces, making the
backup pool your Single point of failure. You _need_ tape - A decent robot and
several drives along with a suitably sized data safe.
We currently back up about 250 million files over 400TB and I'm currently using
a Quantum i500 with 14U extension and 6 SAS LTO6 drives, previously we had a
Overland Neo8000 with 7 FC LTO5 drives.
Once you bite the bullet and use tape, dump the sata spinning disks. Use
something like a raid1 pair of 500GB SM843s for your OS, put in second
dedicated 1TB raid1 pair for the database and use a _fast_ 200-800GB PCIe flash
drive for spool.
10GB networking is an absolute must. Don't try to play games with 1Gb/s
bonding. Any given data stream will only run at 1Gb/s maximum.
On the other hand, the setup above would be an expensive waste of time for
backing up 10TB of data - although for that size you could keep the spinning
media and keep the rest - but bear in mind that 48TB is only going to allow 3
full backups of 15TB (any fewer than 3 full backups is asking for trouble),
without taking differentials or incrementals into account.
For 20TB+ you may want to look at a single-drive tape autochanger capable of
holding at least 10 tapes. The last thing you want to be doing is feeding new
LTO6/7s into it every 2-3 hours when a full backup is running (yes, they will
fill up that quickly)
Director could be on the same physical box but would ideally be a VM with a
couple of CPU cores and as much RAM as is needed to handle a couple dozen
clients, though the largest two clients are around 10TB and each have millions
of files. Impression I get is that network and disk will be a bottleneck way
before RAM and CPU should be?
------------------------------------------------------------------------------
Site24x7 APM Insight: Get Deep Visibility into Application Performance APM +
Mobile APM + RUM: Monitor 3 App instances at just $35/Month Monitor end-to-end
web transactions and take corrective actions now Troubleshoot faster and
improve end-user experience. Signup Now!
http://pubads.g.doubleclick.net/gampad/clk?id=272487151&iu=/4140
_______________________________________________ Bacula-users mailing list
Bacula-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bacula-users
------------------------------------------------------------------------------
Site24x7 APM Insight: Get Deep Visibility into Application Performance
APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
Monitor end-to-end web transactions and take corrective actions now
Troubleshoot faster and improve end-user experience. Signup Now!
http://pubads.g.doubleclick.net/gampad/clk?id=272487151&iu=/4140
_______________________________________________
Bacula-users mailing list
Bacula-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bacula-users
