Hi,

we have a solaris setup in our company and i have been assigned on a project of planning a backup strategy . ours is a midium level company.

please help me so that i can plan an Ideal Backup Strategy.

Thanks,
Una

Well depending on how much data you want to backup. A meduim size company can sometimes have TB's of data. Also is all the data on 1 server? Several servers? etc

Personally I like using tapes still if I am to do a backup. CD's have been known to fail when you need to get data off them, yes even if they are stored in the right environment. DVD's yeah they hold more data though there is no long-term track record of using them for storing data on. Tapes have been used for years.

Or depending on the type of data you want to backup, how much etc you might just want to setup a 2nd HDD and make a image of the main HDD like say once a week.

It all depending on the servers, data size, what your budget is also helps, and so on. I would suggest getting a Unix Administration book on backup and recovry and reading through it and come up with the best plan for your business. Some people like to make there own configuration for the backups instead of using someone else's.


Cheers

The best book on backup is
Implementing Backup and Recovery: The Readiness Guide for the Enterprise

1st thing you have to figure out:
Why is there even a need to backup? Purpose of backup?

Only then you know
How long you need to retent backup?
How freq to backup?
Which server to backup?
....

Thanks for ur quick reply

Its a single server backup of E450 server which has nearly 300 GB of data on it .
it has seperate root disk , spererate user files disk and seperate log disk . so anybody can suggest me the suitable backup plan and how frequently to take .

thanks in anticipation

Una

In a nut shell, one that works effectively when called upon.

The term `Ideal` is ambiguous as different sites have different needs.

I know of a couple of Medium Level Businesses that have inexcess of 2000 servers each. So .......

Get out a pen and paper and start discussing with your company stakeholders what is core business critical systems and what isn't. For example; live/production servers and mail servers are generally considered critical systems, test/develpoment systems are not. Also know ahead of time what your budget is to get the task done. Also have stakeholders identify any SLA, OLA, etc that could be impacted by backup schedules.

Get each of your stakeholders to identify what they require backing up and with what regularity. Don't take this role on yourself, otherwise it could be a case of hit-and-miss. This detail received should include server names, IP addresses, and specific directories for example. Some systems require full-backups every time, other can withstand incremental backups during the week and a full-backup at weeks end (and a monthly backup on the last w/end of the month).

Draw yourself a micky-mouse diagram of what resources you have available to perform backups and spread the load across all resources. If you quickly find that you are running out of time and resources to perform your backups - then raise a red-flag and start making a purchase order

Another tip is to ease into your backup plan. No point flogging everything at the one time to have it all fall over. From the start, keep track of backup statistics - these metrics (amount of data backed-up, tapes used, time taken to perform backup, time period of backup) can be benificial to help reorganise backup scheduling and justify expansion requirements or upgrades.

I know it's a bit brief, but I hope that helps some.

depends on:

1. Size of data (you already indicated 300 GB). What data out this is most important and should be recovered first if data disaster occurs ? Categorize your data.
2. Type of data (Oracle/Sybase/any database, Mail server, development stuff... ) depending on recovery requirements.
3. How frequently your data is changing or what is the daily rate of these changes. Categorizing your data on that basis would be very helpful.
4. What is your downtime window (if any) your business can afford on daily or weekly basis.
5. Do you have intensive data update through off-hour batch processings ?
6. For how long you are required to keep your data. This may be different for different data categories you want to backup.

Without taking above factors into account it's very hard to talk about "Ideal" backup strategy.

Generally speaking,

1. Weekly Full backups for flat file data and cold backup for database (if possible)

2. Daily incremental backups for flat file data and hot backups for database.

3. keeping backups for two months at least.

would make sence in most cases. However, to make it ideal for your business you need to "fine tune" this strategy based on the factors I talked in the begining of my post.

of course, storing some backup volumes off-site is very important.

A backup and recovery strategy cannot be created based on disk size and random guesses as to what is "ideal". A backup and recovery strategy is based on how your company and users use the data! If your company is processing credit card or similar database transaction, and the server is busy, you might be well advised to backup certain files twice a day.

Or, for example, if you have many users on the platform who are writing software, then you must backup, at a mininum, every day, because people get very unhappy when the accidentally delete a file and there is no backup.

The same is true for web hosting and myriad other applications.

Phantom did a good job to begin to describe the process of developing a backup and recovery strategy.

"Know your data." "Know your users."