On Mon, Sep 5, 2011 at 6:53 AM, Adam Goryachev <mailingli...@websitemanagers.com.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 <tmas...@obscorp.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 <tmas...@obscorp.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@lists.sourceforge.net List: https://lists.sourceforge.net/lists/listinfo/backuppc-users Wiki: http://backuppc.wiki.sourceforge.net Project: http://backuppc.sourceforge.net/