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 <misteritguru AT gmx DOT com> wrote:
On 07/01/2011 01:54, Rory Campbell-Lange wrote:
> On 06/01/11, lance raymond ( lance.raymond AT gmail DOT 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).
>
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 AT lists.sourceforge DOT 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 AT lists.sourceforge DOT net
https://lists.sourceforge.net/lists/listinfo/bacula-users
|
