Re: Storage server
Am Montag, 10. September 2012 schrieb Veljko:
> On Sat, Sep 08, 2012 at 09:28:09PM +0200, Martin Steigerwald wrote:
> > Consider the consequenzes:
> >
> > If the server fails, you possibly wouldn´t know why cause the
> > monitoring information wouldn´t be available anymore. So at least
> > least Nagios / Icingo send out mails, in case these are not stored
> > on the server as well, or let it relay the information to another
> > Nagios / Icinga instance.
>
> Ideally, Icinga/Nagios/any server would be on HA system but that,
> unfortunately is not an option. But of course, Icinga can't monitor
> system it's on, so I plan to monitor it from my own machine.
Hmmm, sounds like a workaround… but since it seems your resources are
tightly limited…
> > What data do you backup? From where does it come?
>
> Like I said, it's several dedicated, mostly web servers with users
> uploaded content on one of them (that part is expected to grow). None
> of them is in the same data center.
Okay, so thats fine.
I would still not be comfortable mixing production stuff with a backup
server, but I think you could get away with it.
But then you need a different backup server for the production stuff on the
server and the files from the fileserver service that you plan to run on it,
cause…
> > I still think backup should be separate from other stuff. By design.
> > Well for more fact based advice we´d require a lot more information
> > on your current setup and what you want to achieve.
> >
> > I recommend to have a serious talk about acceptable downtimes and
> > risks for the backup with the customer if you serve one or your boss
> > if you work for one.
>
> I talked to my boss about it. Since this is backup server, downtime is
> acceptable to him. Regarding risks of data loss, isn't that the reason
> to implement RAID configuration? "R" stands for redundancy. If hard
> disk fails, it will be replaced and RAID will be rebuild with no data
> loss. If processor or something else fails, it will be replaced with
> expected downtime of course.
… no again: RAID is not a backup.
RAID is about maximizing performance and/or minimizing downtime.
Its not a backup. And thats about it.
If you or someone else or an application that goes bonkers delete data on
the RAID by accident its gone. Immediately.
If you delete data on a filesystem that is backuped elsewhere, its still
there provided that you notice the data loss before the backup is
rewritten and old versions of it are rotated away.
See the difference?
Ok, so now you can argue: But if I rsnapshot the production data on this
server onto the same server I can still access old versions of it even
when the original data is deleted by accident.
Sure. Unless due to a hardware error like to many disks failing at once or
a controller error or a fire or what not the RAID where the backup is
stored is gone as well.
This is why I won´t ever consider to carry the backup of this notebook
around with the notebook itself. It just doesn´t make sense. Neither for a
notebook, nor for a production server.
Thats why I recommend an *offsite* backup for any data that you think is
important for your company. With offsite meaning at least a different
machine and a different set of harddisks.
If that doesn´t go into the head of your boss I do not know what will.
If you follow this, you need two boxes… But if you need two boxes, why
just don´t do the following:
1) virtualization host
2) backup host
to have a clear separation and an easier concept. Sure you could replicate
the production data of the mixed production/dataserver to somewhere else,
but going down this route it seems to be that you add workaround upon
workaround upon workaround.
I find it way easier if the backup server does backup (and nothing else!)
and the production server does backup (and nothing else). And removing
complexity removes possible sources of human errors as well.
In case you go above route, I wouldn´t even feel to uncomfortable if you
ran some test VMs on the virtualization host. But that depends on how
critical the production services on it are.
Thanks,
--
Martin 'Helios' Steigerwald - http://www.Lichtvoll.de
GPG: 03B0 0D6C 0040 0710 4AFA B82F 991B EAAC A599 84C7
Reply to: