Backup and Recovery Goals
-
OK so from this topic it's become abundantly clear that there are way to many pieces at play. With this I need to break out our objectives to this looming project.
With this assume everything we currently have besides the 1Gb Network backbone is going in the trash. This is a full refresh project.
Goals
-
First off, I need to virtualize every physical server we have.
-
I need a relatively high availability
-
I also need a very solid backup solution, preferably including fulls and incremental changes.
-
I need hourly incremental backup that are maintained for 3 days.
-
A monthly full to use in the event of an catastrophic event on site.
-
4 months of network share backups should be kept for recovery.
-
Avoiding taking anything home on fridays would also be ideal
What we have
4 physical servers, totaling 5,841 GB of Used Storage. This includes C drives and Network Shares. But totals up to 8TB available.Primary File Server
- 3TB Buffalo Terastation where the bulk of our network shares are mounted, attached as iSCSI to the primary file server
DC / File Server
- 1TB Operations Drive on a standalone server
- 400 GB Share
- 2TB External USB LaCie
- a second 2TB External USB LaCie
Server Software
- Storage Craft for incremental and fulls.
- Server OS's 2003 - 2008
Here are two descriptions that are key to what I'm attempting to achieve.
The recovery time objective (RTO) is the targeted duration of time and a service level within which a business process must be restored after a disaster (or disruption) in order to avoid unacceptable consequences associated with a break in business continuity.- RTO time must <= 1 business day.
The recovery point objective (RPO) is the age of files that must be recovered from backup storage for normal operations to resume if a computer, system, or network goes down as a result of a hardware, program, or communications failure.
- RPO must <=1 business hour.
-
-
-
@MattSpeller said:
@DustinB3403 said:
RPO must >=1 business hour.
Greater than 1 hour?
Sign corrected.
-
You are able/willing to lose a month of changes at a time? Is that what I am reading from this? You're RPO and what you mentioned earlier in the post don't match.
-
Are the RTO and RPO goals set by you? Or are they set by management?
-
@coliver said:
You are able/willing to lose a month of changes at a time? Is that what I am reading from this? You're RPO and what you mentioned earlier in the post don't match.
No the fulls are only for site catastrophes. Incrementals are to be used to recover files from day to day.
But I do want a way to backup my VM's primary partitions exclusively for a faster recovery. (if at all possible)
-
@coliver said:
Are the RTO and RPO goals set by you? Or are they set by management?
By me and having heard management say we can't live with more. Not my call to argue with them, that's my bosses job.
-
@DustinB3403 said:
Here are two descriptions that are key to what I'm attempting to achieve.
The recovery time objective (RTO) is the targeted duration of time and a service level within which a business process must be restored after a disaster (or disruption) in order to avoid unacceptable consequences associated with a break in business continuity.- RTO time must <= 1 business day.
The recovery point objective (RPO) is the age of files that must be recovered from backup storage for normal operations to resume if a computer, system, or network goes down as a result of a hardware, program, or communications failure.
- RPO must <=1 business hour.
Something to keep in mind. While every business wants as little downtime as possible and as little data lose as possible, while they may start with that goal, and give the times listed above, once you provide them numbers that provide that level of service, they may come back and change their minds and lower these requirements (i.e. make them longer).
-
@Dashrender said:
@DustinB3403 said:
Here are two descriptions that are key to what I'm attempting to achieve.
The recovery time objective (RTO) is the targeted duration of time and a service level within which a business process must be restored after a disaster (or disruption) in order to avoid unacceptable consequences associated with a break in business continuity.- RTO time must <= 1 business day.
The recovery point objective (RPO) is the age of files that must be recovered from backup storage for normal operations to resume if a computer, system, or network goes down as a result of a hardware, program, or communications failure.
- RPO must <=1 business hour.
Something to keep in mind. While every business wants as little downtime as possible and as little data lose as possible, while they may start with that goal, and give the times listed above, once you provide them numbers that provide that level of service, they may come back and change their minds and lower these requirements (i.e. make them longer).
Right, but that is for management to decide. For right now this is part of the requirements.
-
We currently managed a <=1 Hour RPO with Storage Craft for our network shares.
I would like to maintain that, and ideally if possible expand it to the entire virtual machines.
-
Excluding replacing hardware. <=1 RPO for VM's and data.
If hardware dies that's as fast as the truck can get here.
-
I've had to update the original topic, it's not 1 full backup should be kept for recovery. But 4, as this is what we do currently. Well 4 months worth of incremental backups are kept.
To be clear.
-
Revised again as it's still confusing even when I read it.
We keep 4 months worth of network share backups for recovery. This data is compressed and readily available to restore from should we need it.
The 3 day incrementals some how get built into this but these are "always there" to restore from. Nothing special in recovery from this.
-
@DustinB3403 said:
- Avoiding taking anything home on fridays would also be ideal
IronMountain for the win.
-
@DustinB3403 said:
Primary File Server
- 3TB Buffalo Terastation where the bulk of our network shares are mounted, attached as iSCSI to the primary file server
That would be your SAN. iSCSI can't be a file server. It's just storage behind the actual file server which must be a VM somewhere.
-
@scottalanmiller said:
That would be your SAN. iSCSI can't be a file server. It's just storage behind the actual file server which must be a VM somewhere.
In his case it's a 2008 Server that we know of from the other thread.
-
Are you including the 3 TB of data on the Terrastation in your 6 TB of data?
-
The primary file server is directly connected to the Buffalo drive. The server simply shares out the attached stored.
The primary DC has multiple functions on it, Spiceworks, AD, and 2 network shares.
The 3rd server is acting as a HyperV host for 0365 / AD integration and a Reporting server.
@Dashrender said:
Are you including the 3 TB of data on the Terrastation in your 6 TB of data?
Yes.
-
In the other thread you mentioned that StorageCraft was installed on it's own box.. did I misunderstand that?
-
So 3 TB of your data is coming from the network shares - where is the rest of it? More shares? on other servers? DBs?
