On Mon, Sep 5, 2011 at 6:53 AM, Adam Goryachev
<mailinglists AT websitemanagers.com DOT au> wrote:
>
> I think the answer to most of this might have been:
> apt-get --purge remove backuppc
>
> This should remove every trace of the package ever having been
> installed. I only mention this because it might come in handy in the
> future for you.
>
> In addition, you do realise that every distribution of linux can be
> installed with, or without, the graphical user interface (X Windows +
> window manager/etc). In fact, you could even install and setup your
> server with it installed and then un-install it later, or vice-versa....
Adam,
Thanks so much for your helpful message and especially for your
forbearance and encouragement.
Yes, I do, and I have been playing around over the years with
Fedora/CentOS a bit, but have found the learning curve just a bit less
steep on the Debian-esque distros and therefore built up a bit more
experience there. Since my learning objectives are aimed at BackupPC
for now, I wanted to eliminate as many roadblocks as I could.
The fact that a post-disaster recovery scenario would most likely
involve relatively untrained people was also a factor. If a recovery
server could be provided via a customized BackupPC LiveCD, that would
greatly improve the resilience and time-to-recover of our DR plan, and
(again my perception is) that there is a great variety of
user-friendly tools for building LiveCD "custom distros" in
Debian/Ubuntu than Fedora/CentOS.
All of which I recognize is down-the-road pie-in-the-sky pipe-dreaming
from my current state of knowledge.
On Mon, Sep 5, 2011 at 12:03 AM, Timothy J Massey <tmassey AT obscorp DOT com>
wrote:
> +1. This was the exact point I was trying to make.
> As an additional point to the original poster: you said somethng like "OK,
> I'll start over, but with my original config and pool.". NO!!! Start with a
> 100% clean setup. Make it work, and document EVERY LITTLE THING you do to
I just meant I'd keep them when wiping the drive. In the case of the
config.pl, for later reference - I'm using diff tools to check against
the original, changing one parameter at a time and then testing.
Re the cpool, initial experiments start empty with it empty testing
against a small test dirstruc, but once I start working again on the
real system drive excludes, "pre-populating" that to save
unnecessarily waiting for 18GB back over the wire.
On Mon, Sep 5, 2011 at 12:15 AM, Timothy J Massey <tmassey AT obscorp DOT com>
wrote:
> So, you understand that each distribution is going to set things up
> differently, which is very likely to contribute to future problems, yet you
> decide to voluntarily deal with such problems. All of this after stating
> that you do not have sufficient skills to even know when you *might* be
> running into problems.
I plan on experimenting with my advanced goals only after the actual
backups are working successfully, leaving that setup alone and working
with a separate test system. And I do think I have (or am developing)
the skills to be able to see when things are going wrong. Such testing
is how I like to learn, pushing the envelope of what's possible.
>You want to dangle a hard drive onto a production server, put BackupPC on that
>server and consider that a backup? This is wrong on *SO* many levels. It's
>the wrong configuration, it's the wrong tool and it's serving a purpose that
>makes almost no sense.
Sorry if I wasn't more clear. I didn't mean a "production server" in
the sense of adding BackupPC to a server fullfilling another function,
I meant "the production BackupPC server", the one actually doing real
backups, as opposed to my testing environment.
> Why would you create a solution such that when one system fails, you risk
> losing both the production data AND THE BACKUP DATA all at the same time.
> Imagine a power supply failure. Couldn't it take out both hard drives? Sure
> can. How about a malicious user that runs "rm -rf /". Gonna wipe out the
> backup data too. I can come up with a DOZEN scenarios with zero effort.
I don't understand how you get that, in fact I think the opposite.
That would be true if I were relying on RAID, leaving my multiple
drives in sync with each other, but in fact the three drives in
rotation will each be completely independent instances - here's the
link to my original post asking for feedback on that:
http://comments.gmane.org/gmane.comp.sysutils.backup.backuppc.general/27289
> If a 35% solution works for you, great. But most people would usually prefer
> a more useful one.
Of course if I'm given solid details on why my scheme shouldn't work I
won't implement it.
Of if I thought it necessary, we could implement this scheme *in
addition* to a traditional static instance of BackupPC, but at this
point I believe that would only be necessary once sufficient history
won't fit on a single large drive. In which case the offsite rotation
drives would only hold a more recent subset of that stored on the big
RAID array, but it would still likely be many month's worth of full
backups per disk.
>My time is too valuable to put band-aids on people who after being told not to
>run with scissors (and acknowledge the stupidity of running with scissors),
>insist on doing it (again).
> Ah, but your backwards of accomplishing this does not encourage at least me
> to help you in the least.
I'm sorry I don't understand "backwards of accomplishing this". But I
completely understand your desire to conserve your time
Thank you for spending the time you have done so far to give me this
advice and I certainly will take it into consideration.
------------------------------------------------------------------------------
Special Offer -- Download ArcSight Logger for FREE!
Finally, a world-class log management solution at an even better
price-free! And you'll get a free "Love Thy Logs" t-shirt when you
download Logger. Secure your free ArcSight Logger TODAY!
http://p.sf.net/sfu/arcsisghtdev2dev
_______________________________________________
BackupPC-users mailing list
BackupPC-users AT lists.sourceforge DOT net
List: https://lists.sourceforge.net/lists/listinfo/backuppc-users
Wiki: http://backuppc.wiki.sourceforge.net
Project: http://backuppc.sourceforge.net/
|
