Zero Backup

Some companies have begun to do away with traditional backup that supports a concept called zero backup, where there is no backup was made. Is zero backup is really the way of the future?Over recent years the nature of backup data centers have evolved into something almost unrecognizable. In the not too distant past, the accepted way of doing backups is to put a bunch of cassette tapes and let the magazine run up late at night. Today, this approach is rarely a viable option. Most data centers operate 24 hours a day, which makes the concept obsolete nightly backup.In addition to time constraints, there are many additional factors that will change the way the backup should be done. These factors run the gamut from the recovery time objective for service level agreements. Because of these and other factors that countless organizations have been forced to adopt technologies such as next-generation backup backup backup snap shot or continuous data protection. Still others have adopted a more radical approach - the concept of backup just leave altogether.The concept has come to be known reserves left as zero reserves. The basic idea behind zero backup is that if you have enough redundancy in place then there is no need for a backup.Technically zero backups can still be considered as a backup - albeit very non-traditional. After all, the backup is really nothing more than a copy of your data is stored in a safe place so it can be restored if something ever happens to the primary data source. Backup zero may not involve copying data to tape or other backup media, but the redundancy involved in the underlying architecture ensures that there are multiple copies of the organization's data. Therefore, it could still be considered zero backup as the backup type.So how zero backup work? I first heard the concept about a year ago related to Exchange Server 2010, but the concept has since expanded to include other server products. Even so, I will talk about zero backups of Exchange Server candidate since zero backup for Exchange has been used for a while.It makes zero backup for Exchange Server is probably the structure known as the Database Availability Group. Database availability group failover cluster similar in that they provide the Exchange server box with redundancy and fault tolerance. In fact, even the availability of the database relies on Windows Failover Cluster Services. Unlike other types of cluster failover However, database availability groups Exchange does not rely on shared storage.Lack of shared storage is one key to back up practical zero. In a cluster that relies on shared storage, storage itself (and the data stored in the storage array) can be a single point of failure. In the Database Availability Group, mailbox database replicated between cluster nodes.Those familiar with Exchange Server may be quick to point out that the Exchange 2007 database replication capabilities are also offered through local continuous replication and Replication constantly alert. Database availability groups can be considered as the next generation solution continuous replication.Cluster continuous replication deployment typically consists of either three or two-node cluster nodes and cluster file share witness. Conversely, an Exchange 2010 database availability group can include up to 16 mailbox servers.In most cases, has sixteen replica of the mailbox database would be overkill, but the number of mailbox servers in a database availability group does not necessarily reflect the number of database replicas. The reason for this is simple. Each mailbox server that can accommodate multiple Exchange Server database. Exchange 2010 database availability groups let you host your database locally on each database availability group member, but they also allow you to replicate the database for each member of a database availability group that you select. Replication performed at a database level, not on a per server. That means that you are free to replicate several databases and not others or to replicate different databases to database availability group members are different.So what does all this have to do with zero backup? In the case of Exchange Server, database replication boxes are usually configured in a way that provides the greatest resilience.Of course there is a difference between fault tolerance and backing up your data, so you may be wondering how the database availability group can facilitate things like point in time recovery or offsite storage.Offsite storage is made possible by the fact that the availability datacenter single database can span. For example, if your organization has data centers in Miami and Las Vegas then you can create a single database availability groups and mailbox covers server from both locations. You may have multiple Exchange Servers in Miami which is usually in the service user's Miami office. Database servers can be replicated their mailboxes to Las Vegas datacenter for safe keeping. Similarly, Exchange Server in Las Vegas office may include a mailbox for the user in the Las Vegas office, but they can be replicated mailbox database to Miami. Basically, each server box in the availability of database replicas has the potential to host a database of both Miami and Las Vegas. You are free to mix and match the replica as your needs dictate.Although offsite replica gives you a way to keep a copy offsite data server mailbox, there is still a problem point in time recovery. Suppose for example that the mailbox database full of viruses. Damage to the database will be replicated to all other database replicas. So how can you restore the database to a previous point in time if you do not do backups?Exchange 2010 offers a feature called copy behind. Left is a replica copy of the database set up so that the changes are not immediately committed to the database. For example, you might set a replica of the database with a time lag of the day. Replication others may have a week lag time. If the unthinkable should happen then you can use the replica left to return to the point in time before the database corruption that has ever happened.Throughout this article, I have shown you how the database availability group could conceivably make a traditional backup unnecessary. Even so, we must ask whether this and similar technologies actually do away with the need for traditional backup.Several organizations have been totally committed to using zero backup. The organization has sufficient redundancy in a place that they do not feel as if they even need to make a backup again.Personally, I would be really nervous about the idea of ​​giving up my backup supports backup zero. Despite the availability of databases and similar technology could potentially eliminate the need for a backup, I have worked in IT long enough to know that sometimes the unexpected happens. If disaster ever did result in data loss, I just can not imagine having to explain to my clients that their data is lost because I choose not to back up. For those who work in the corporate world, I would imagine that it would equally not fun trying to explain to your boss why you have no backup.