Thanks to all replies, have have done most of the reading to get the ball rolling. It's installed on a test server that has access to a few web servers and I will use that as the 'test' bed ....
Promise next post will be a little more intelligent as I go forward, and love the " Just my babblings, hope it helps." as those are the things that do help, it's when you go back to edit, etc. it becomes to professional :) Regards... Lr On Fri, Jan 7, 2011 at 7:22 AM, Mister IT Guru <misteritg...@gmx.com> wrote: > On 07/01/2011 01:54, Rory Campbell-Lange wrote: > > On 06/01/11, lance raymond (lance.raym...@gmail.com) wrote: > >> I have around 1T of storage compressed (numerous servers, websites, > >> database, etc.) and around 1 1/2T to store so I can't do a live copy of > the > >> files nor can I keep more than 1 full copy. The old backup system is > not in > >> good condition and I would like to have the following > > First of all this is a bit confusing. Are you saying you have 1TB of > > data to store and 1.5TB to store it in on the backup server? > > > >> Initial image of key folders per server, then nightly incremental > updates. > >> You just can't do that with basic tools, so can bacula from a central > box > >> go out nightly, and update in that way (I did say it was a high level). > > > Well, I think the best thing for you to do, will be to get bacula up and > working with a test server, and a test client, make the client something > easy, like a VM of a basic linux instance. Then learn about schedules, > and files sets. Then identify all your critical files, and have them in > one backup set, as aggressive as you like, so at least you have your own > piece of mind. > > I'm assuming that your going to use a disk based backend. Run a complete > full of each client in question, run incremental every day for a week, > then run a differential. That would give you a basic idea of how much > space you should need, because at the very least in your backup set you > must have 1 full, and either all the incremental up to present, or 1 > full, 1 diff, and all the incremental after that diff - in order to get > back to a specific point in time. > > This is just a start, to be honest, backup policies are only as good as > the people who carry them out - so you'll also have to test restoring > the backups you do make. Once you have a configuration that works, nuke > you bacula DB (there have been posts very recently on the list in this > regard), and leave your backups in the hands of bacula, knowing that > what works on paper, also works in the real world. > > note: Once you nuke the bacula DB, you'll have to manually run a full > backup, at least so that you get that nice glowing feeling that your > data is secure again. (and so that you don't get hit by Sods Law) > > Just my babblings, hope it helps. > > > ------------------------------------------------------------------------------ > Gaining the trust of online customers is vital for the success of any > company > that requires sensitive data to be transmitted over the Web. Learn how to > best implement a security strategy that keeps consumers' information secure > and instills the confidence they need to proceed with transactions. > http://p.sf.net/sfu/oracle-sfdevnl > _______________________________________________ > Bacula-users mailing list > Bacula-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/bacula-users >
------------------------------------------------------------------------------ Gaining the trust of online customers is vital for the success of any company that requires sensitive data to be transmitted over the Web. Learn how to best implement a security strategy that keeps consumers' information secure and instills the confidence they need to proceed with transactions. http://p.sf.net/sfu/oracle-sfdevnl
_______________________________________________ Bacula-users mailing list Bacula-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users
