Backup Central

Just an FYI, you probably avoided this problem (the hard way) by
manually installing some of the perl packages. They are available in
an optional RHEL (not EPEL) repository that is disabled by default.
See the following bug for details:

https://bugzilla.redhat.com/show_bug.cgi?id=740276

Richard

------------------------------------------------------------------------------
The demand for IT networking professionals continues to grow, and the
demand for specialized networking skills is growing even more rapidly.
Take a complimentary Learning < at > Cisco Self-Assessment and learn
about Cisco certifications, training, and career opportunities.
http://p.sf.net/sfu/cisco-dev2dev
_______________________________________________
BackupPC-users mailing list
BackupPC-users < at > lists.sourceforge.net
List: https://lists.sourceforge.net/lists/listinfo/backuppc-users
Wiki: http://backuppc.wiki.sourceforge.net
Project: http://backuppc.sourceforge.net/

Actually I read about enabling the "optional" RHEL repo while researching this problem so I had done that as well.
Manually installing things made it so the system only had to get that last dependency and then it went ahead and installed BackupPC.
Reading the docs, it's the final frontier...

Now the real fun starts, getting BackupPC configured and working.
Sometimes I wonder how I get myself into these things.

Rick Bastedo


On Thu, Oct 27, 2011 at 6:57 AM, Richard Shaw <hobbes1069 < at > gmail.com ([email]hobbes1069 < at > gmail.com[/email])> wrote:
Just an FYI, you probably avoided this problem (the hard way) by
manually installing some of the perl packages. They are available in
an optional RHEL (not EPEL) repository that is disabled by default.
See the following bug for details:

https://bugzilla.redhat.com/show_bug.cgi?id=740276

Richard

On Thu, Oct 27, 2011 at 9:19 AM, Rick Bastedo <rbastedo < at > gmail.com> wrote:
Actually I read about enabling the "optional" RHEL repo while researching
this problem so I had done that as well.
Manually installing things made it so the system only had to get that last
dependency and then it went ahead and installed BackupPC.
Reading the docs, it's the final frontier...

Now the real fun starts, getting BackupPC configured and working.
Sometimes I wonder how I get myself into these things.

From the RPM install it should just come up working with the the usual
'service' and 'chkconfig' operations to activate it, although iptables
and/or SELinux might prevent access. See the comment in
/etc/httpd/conf.d/BackupPC.conf about adding a web user password. It
should be easy enough to get your data into backuppc at that point.
I'm still curious about how you plan to get it to your DPM.

--
Les Mikesell
lesmikesell < at > gmail.com

------------------------------------------------------------------------------
The demand for IT networking professionals continues to grow, and the
demand for specialized networking skills is growing even more rapidly.
Take a complimentary Learning < at > Cisco Self-Assessment and learn
about Cisco certifications, training, and career opportunities.
http://p.sf.net/sfu/cisco-dev2dev
_______________________________________________
BackupPC-users mailing list
BackupPC-users < at > lists.sourceforge.net
List: https://lists.sourceforge.net/lists/listinfo/backuppc-users
Wiki: http://backuppc.wiki.sourceforge.net
Project: http://backuppc.sourceforge.net/

"I'm still curious about how you plan to get it to your DPM."

As am I.

I'm taking a 'one step at a time' approach here.
My network admin hasn't given me the storage share address yet nor do I have permission on the system that is to be backed up.
I've got BackupPC installed, and am waiting until I get the information I need from him before I do configuration.
Meanwhile I suppose getting the rest of the system ready would be a good idea at this point.

Rick Bastedo

On Thu, Oct 27, 2011 at 8:47 AM, Les Mikesell <lesmikesell < at > gmail.com ([email]lesmikesell < at > gmail.com[/email])> wrote:
On Thu, Oct 27, 2011 at 9:19 AM, Rick Bastedo <rbastedo < at > gmail.com ([email]rbastedo < at > gmail.com[/email])> wrote:
Actually I read about enabling the "optional" RHEL repo while researching
this problem so I had done that as well.
Manually installing things made it so the system only had to get that last
dependency and then it went ahead and installed BackupPC.
Reading the docs, it's the final frontier...

Now the real fun starts, getting BackupPC configured and working.
Sometimes I wonder how I get myself into these things.


From the RPM install it should just come up working with the the usual
'service' and 'chkconfig' operations to activate it, although iptables
and/or SELinux might prevent access.   See the comment in
/etc/httpd/conf.d/BackupPC.conf about adding a web user password.  It
should be easy enough to get your data into backuppc at that point.
I'm still curious about how you plan to get it to your DPM.

--
 Les Mikesell
   lesmikesell < at > gmail.com ([email]lesmikesell < at > gmail.com[/email])

The Systems Admin told me they are setting up a 5TB NFS share for me to use.
Any gotcha's anyone can think of before I go ahead with configuration? There's nothing like diving right into the deep end.

They will be having me back up more Linux systems after I successfully take care of the big sore point they have currently.
Which is (current plan) to back up the database backups, four backups on a client machine dated from most recent to oldest copies currently about 36GB each.
So (though I haven't seen it) I am thinking there will be four backup directories which will be a lot like each other with minor differences.
I've been asked if there's a way to just get things that are newer than NN hours only, which I don't know - I said I'd get back to them on that.

So the current thinking is that the databases are backed up using whatever our vendor uses to do backups, this is their responsibility according to their SLA.
In order to provide disaster recovery (partially our responsibility) we will move those resulting database backup files to our NFS share via BackupPC and then backup that NFS to our DPM tape repository which gets sent out to Iron Mountain weekly.
The restore process for disaster recovery purposes should be that of letting the vendor rebuild the system according to their SLA, then we will supply the database backup file set they request and they will perform the database restore.

After we demonstrate success with this then we will identify other clients and add more to our backups, but first things first.

ANY advice to this BackupPC noob is appreciated, I am learning things as I read everyone's messages.

Rick Bastedo




On Thu, Oct 27, 2011 at 9:14 AM, Rick Bastedo <rbastedo < at > gmail.com ([email]rbastedo < at > gmail.com[/email])> wrote:
"I'm still curious about how you plan to get it to your DPM."


As am I.

I'm taking a 'one step at a time' approach here.
My network admin hasn't given me the storage share address yet nor do I have permission on the system that is to be backed up.
I've got BackupPC installed, and am waiting until I get the information I need from him before I do configuration.
Meanwhile I suppose getting the rest of the system ready would be a good idea at this point.

Rick Bastedo

On Thu, Oct 27, 2011 at 8:47 AM, Les Mikesell <lesmikesell < at > gmail.com ([email]lesmikesell < at > gmail.com[/email])> wrote:
On Thu, Oct 27, 2011 at 9:19 AM, Rick Bastedo <rbastedo < at > gmail.com ([email]rbastedo < at > gmail.com[/email])> wrote:
Actually I read about enabling the "optional" RHEL repo while researching
this problem so I had done that as well.
Manually installing things made it so the system only had to get that last
dependency and then it went ahead and installed BackupPC.
Reading the docs, it's the final frontier...

Now the real fun starts, getting BackupPC configured and working.
Sometimes I wonder how I get myself into these things.


From the RPM install it should just come up working with the the usual
'service' and 'chkconfig' operations to activate it, although iptables
and/or SELinux might prevent access.   See the comment in
/etc/httpd/conf.d/BackupPC.conf about adding a web user password.  It
should be easy enough to get your data into backuppc at that point.
I'm still curious about how you plan to get it to your DPM.

--
 Les Mikesell
   lesmikesell < at > gmail.com ([email]lesmikesell < at > gmail.com[/email])

On Mon, Nov 7, 2011 at 12:22 PM, Rick Bastedo <rbastedo < at > gmail.com> wrote:
The Systems Admin told me they are setting up a 5TB NFS share for me to use.
Any gotcha's anyone can think of before I go ahead with configuration?

Are you planning to mount the NFS share as the top of the backuppc
archive directory, or use it as a target to export tar archives either
with scripted Backuppc_tarCreate commands or 'archive host'
configurations?

They will be having me back up more Linux systems after I successfully take
care of the big sore point they have currently.

If the system ends up doing some type file-oriented copy from the NFS
share to tape, it will likely fail at some point if that is your whole
backuppc archive due to the large number of hardlinked files it will
accumulate.

I've been asked if there's a way to just get things that are newer than NN
hours only, which I don't know - I said I'd get back to them on that.

Maybe - if you modify the command issued to collect the copies.

So the current thinking is that the databases are backed up using whatever
our vendor uses to do backups, this is their responsibility according to
their SLA.
In order to provide disaster recovery (partially our responsibility) we will
move those resulting database backup files to our NFS share via BackupPC and
then backup that NFS to our DPM tape repository which gets sent out to Iron
Mountain weekly.
The restore process for disaster recovery purposes should be that of letting
the vendor rebuild the system according to their SLA, then we will supply
the database backup file set they request and they will perform the database
restore.

I think you can make this work, but it isn't the sort of thing
backuppc does best. On the other hand if you don't actually have a
site disaster, it may be handy to be able to grab the copy that
backuppc still has online.

After we demonstrate success with this then we will identify other clients
and add more to our backups, but first things first.

You'll see much more benefit from backuppc's features from targets
where you have duplication across machines, or directories where only
a few files change per run.

--
Les Mikesell
lesmikesell < at > gmail.com

------------------------------------------------------------------------------
RSA(R) Conference 2012
Save $700 by Nov 18
Register now
http://p.sf.net/sfu/rsa-sfdev2dev1
_______________________________________________
BackupPC-users mailing list
BackupPC-users < at > lists.sourceforge.net
List: https://lists.sourceforge.net/lists/listinfo/backuppc-users
Wiki: http://backuppc.wiki.sourceforge.net
Project: http://backuppc.sourceforge.net/

I am planning on mounting the share as the TopDir.
I'm going to start small and see where it fails, then deal with it.
This part sounds like it would be a lot simpler and way more effective to tar archive everything we want to store and then copy the results to tape.

Or - there's a way to tar archive and stream it to the NFS share using BackupPC - if I can manage to do that it might just solve problems.
Whatever happens it has to go straight to the NFS as that's the only storage I'll have that's big enough to take anything.

Rick


On Mon, Nov 7, 2011 at 11:48 AM, Les Mikesell <lesmikesell < at > gmail.com ([email]lesmikesell < at > gmail.com[/email])> wrote:
On Mon, Nov 7, 2011 at 12:22 PM, Rick Bastedo <rbastedo < at > gmail.com ([email]rbastedo < at > gmail.com[/email])> wrote:
The Systems Admin told me they are setting up a 5TB NFS share for me to use.
Any gotcha's anyone can think of before I go ahead with configuration?


Are you planning to mount the NFS share as the top of the backuppc
archive directory, or use it as a target to export tar archives either
with scripted Backuppc_tarCreate commands or 'archive host'
configurations?

They will be having me back up more Linux systems after I successfully take
care of the big sore point they have currently.


If the system ends up doing some type file-oriented copy from the NFS
share to tape, it will likely fail at some point if that is your whole
backuppc archive  due to the large number of hardlinked files it will
accumulate.

I've been asked if there's a way to just get things that are newer than NN
hours only, which I don't know - I said I'd get back to them on that.


Maybe - if you modify the command issued to collect the copies.

So the current thinking is that the databases are backed up using whatever
our vendor uses to do backups, this is their responsibility according to
their SLA.
In order to provide disaster recovery (partially our responsibility) we will
move those resulting database backup files to our NFS share via BackupPC and
then backup that NFS to our DPM tape repository which gets sent out to Iron
Mountain weekly.
The restore process for disaster recovery purposes should be that of letting
the vendor rebuild the system according to their SLA, then we will supply
the database backup file set they request and they will perform the database
restore.


I think you can make this work, but it isn't the sort of thing
backuppc does best.  On the other hand if you don't actually have a
site disaster, it may be handy to be able to grab the copy that
backuppc still has online.

After we demonstrate success with this then we will identify other clients
and add more to our backups, but first things first.


You'll see much more benefit from backuppc's features from targets
where you have duplication across machines, or directories where only
a few files change per run.

--
  Les Mikesell
    lesmikesell < at > gmail.com ([email]lesmikesell < at > gmail.com[/email])

On Mon, Nov 7, 2011 at 2:37 PM, Rick Bastedo <rbastedo < at > gmail.com> wrote:
I am planning on mounting the share as the TopDir.
I'm going to start small and see where it fails, then deal with it.

Umm, is it wise to plan something that you expect to fail under
typical conditions?

This part sounds like it would be a lot simpler and way more effective to
tar archive everything we want to store and then copy the results to tape.

Except that (a) restoring it isn't likely to work completely correctly
even if you can copy it, (b) you'll have to restore it to an
identically-configured backuppc instance to access the files, and (c)
you'll probably be in a hurry to access the last-saved db copy but
you'll have to restore the entire backuppc archive first before you
can get it.

Or - there's a way to tar archive and stream it to the NFS share using
BackupPC - if I can manage to do that it might just solve problems.

A simple cron job could copy the file in it's usable form to the place
the tape archiver will pick it up. And backuppc could make its own
copy separately so you'd only need the tape in case of a disaster.

Whatever happens it has to go straight to the NFS as that's the only storage
I'll have that's big enough to take anything.

Big disks are cheap these days. Or use one part of the NFS share for
backuppc, another for what you send to tape.

--
Les Mikesell
lesmikesell < at > gmail.com

------------------------------------------------------------------------------
RSA(R) Conference 2012
Save $700 by Nov 18
Register now
http://p.sf.net/sfu/rsa-sfdev2dev1
_______________________________________________
BackupPC-users mailing list
BackupPC-users < at > lists.sourceforge.net
List: https://lists.sourceforge.net/lists/listinfo/backuppc-users
Wiki: http://backuppc.wiki.sourceforge.net
Project: http://backuppc.sourceforge.net/

Whatever happens it has to go straight to the NFS as that's the only storage>> I'll have that's big enough to take anything.>> Big disks are cheap these days.  Or use one part of the NFS share for> backuppc, another for what you send to tape.
Echo Les, what he said.

You will find your BackupPC instance will come in very handy for
ad-hoc restores, and its deduping will allow you to keep versioning
archives long-term.

But IMO don't bother having them backup the whole TopDir, or if you do
try that, treat it as a completely separate run of the tape system,
separate physical tape sets etc, it's just "would be nice if it works"
ie "we might be able to reconstruct the BackupPC instance from tape
but won't count on it."

Set up a secondary mount point (let's call it DumpDir) for scheduled
"dump to tape" jobs per client/target host - those are the targets for
your tape jobs. This means the tape archive process won't benefit from
BPC's de-duplication, but speed/ease of recovery in a true disaster is
the goal there not saving media space. These are temporary dumps, have
your process deleted when the next dump runs.

Note that this TopDir filesystem, although it in effect will contain
the contents of hundreds of DumpDir instances down the road, will
actually take up a very small fraction of your allocated actual disk
space, depending on #hosts and degree of duplication between them. Be
very careful you don't allow your total space to fill up - ideally you
want TopDir on its own dedicated filesystem. Otherwise perhaps keep
more than one instance per host in your DumpDir, so you can quickly
wipe them out when your monitoring system let's you know you're
hitting the say 80% threshold, giving your team time to fulfill your
request for more disk space.

As you seem to be aware, the lack of an overall centrally coordinated
plan by a BackupPC expert means you'll end up with a bit of a
square-peg-round-hole end result, but if the resources are there to
accommodate the resulting hodgepodge, the result can still be
reliable; in fact it will result in resource-inefficient redundancy
that might just come in handy down the road

If it turns out the filesystem you're allocated is too precious for
them to be able to accommodate the above, then make sure you put the
BackupPC TopDir on the most reliable and expandable filesystem
(probably the expensive one) and just use a big cheap drive for the
"scratch" DumpDir filesystem targeted by their tape system.

Disclaimer - above is based on background knowledge from general
experience, if it conflicts with what anyone else tells you here
regarding BackupPC, best to follow them rather than me.

------------------------------------------------------------------------------
RSA(R) Conference 2012
Save $700 by Nov 18
Register now
http://p.sf.net/sfu/rsa-sfdev2dev1
_______________________________________________
BackupPC-users mailing list
BackupPC-users < at > lists.sourceforge.net
List: https://lists.sourceforge.net/lists/listinfo/backuppc-users
Wiki: http://backuppc.wiki.sourceforge.net
Project: http://backuppc.sourceforge.net/