Do you make an image backup on your server every week?

[rz30]

Full drive or partition whatever, i read that some people do this maybe once a week or more, that will add up to a fair amount of storage after a while, is this standard practice?

Also what is your other backup procedure?

Diff Backup of dbs every xx mins?
Diff backup of system state every xx mins?
Diff backup of shared folders every xx mins?

What else do you backup, logs etc... or are these secrets of the trade?

 

[iaind]

There is no standard practice, you need to consider:

- RTO (recovery time objective), how long can you afford to be wait to recover from backup?
- RPO (recovery point objective), how out of data can the data be after a recovery?
- Budget
- Number of servers, total size and the applications installed on them.
- Retention period for historical data
- Server resources available

I've been playing with Acronis recently - the deduplication works quite well and means you can have full images with much less storage than would otherwise be required.

Personally I have the following setup:

- Replication of critical systems in real time offsite which can be recovered in an hour or so. This is for disaster recovery, eg fire/flood etc
- Weekly full backup/nightly differential backup of most servers to a NAS. This is for short term brick level recovery.
- Monthly archive of most servers to tape, stored offsite in a fire proof safe

 

[Sin_Chase]

For servers 'boggo standard' will often be tapes including all data and system states one nightly.

Next step is with bare metal Disaster Recovery plugins.

Then at the higher end of the scale you will have snapshotting and live WAN block level replication.

As iaind has said, your budget and actual requirements will dictate what you use.

 

[silworth]

Our environment is virtual, and as such, daily snapshots are taken of the servers, which are then backed up (using Backup Exec 2010 - beta, I know, but nothing else works with S2008R2) to tape via our automatic tape library.

The entire SAN is replicated to a duplicate, and we have the bare metal capacity to run all our virtual servers twice over (at least). In theory we are fully redundant, and can perform a full disaster recovery scenario in less than 8 hrs even assuming all hardware has failed at the same time.

 

[Little_Crow]

All of our virtual servers have full images taken every night - except 1 which has a vast amount of data and has its C Drive image taken nightly, and incremental backups of the data.

The physical servers have no images taken, though we have a DR project which involves virtualising everything that possibly can be, which will only leave some Unix boxes.

The eventual plan which should be in place by June, is to use VMWare's Site Recovery Manager and have it possible to fail all VM's over to our 2nd site within minutes (Failing back is a whole other issue).

iand has it bang on though, sounds like he's 'been there, done that'. There is no standard practice, it's all down to funds, individual circumstances, funds, available downtime, ?criticalness? of the server, and funds again.

 

[Nikumba]

We perform full nightly backups of most of out 50 servers, staged through a SAN then off to an LTO4 drive, we also back up the system state.

In the event of DR we just restore the tapes.

We are moving to VM with our exchange system and will start to virtulise more servers as time goes on.

Kimbie

 

[bigredshark]

Personally I don't like imaging machines at all, backup your files, backup your databases and when you need to, restore them into a DR environment (if you don't have live replication to the backup site). I believe in a high end environment it should never really be necessary to bare metal restore a machine, not everybody can operate that type of environment but I think it's the standard to aim for...

 

[Sin_Chase]

Personally I don't like imaging machines at all, backup your files, backup your databases and when you need to, restore them into a DR environment (if you don't have live replication to the backup site). I believe in a high end environment it should never really be necessary to bare metal restore a machine, not everybody can operate that type of environment but I think it's the standard to aim for...

Most small to medium businesses that need a working DR plan either do not have the staff, resources, time and/or knowledge to implement version control and consistent updates of DR servers.

Even if they did, you miss a service pack, some hotfixes or some core system changes then you are potentially screwing your restore process (PARTICULARLY Exchange) and left having to rebuild everything and restore data in isolation.

 

[bigredshark]

Most small to medium businesses that need a working DR plan either do not have the staff, resources, time and/or knowledge to implement version control and consistent updates of DR servers.

Even if they did, you miss a service pack, some hotfixes or some core system changes then you are potentially screwing your restore process (PARTICULARLY Exchange) and left having to rebuild everything and restore data in isolation.

Well I did say not everybody can do it for cost reasons. But there's no excuse for missing stuff and having inconsistent environments, that's a failure of change control and indicative of a management failure.

And it should be picked up in your frequent DR tests of course...