Don’t save your VM backups in the SAN where you run them!

0 Flares Twitter 0 Facebook 0 LinkedIn 0 Email -- 0 Flares ×

As Dr. Egon Spengler said in the Ghostbusters movie, “Don’t cross the streams. It’s would be BAD” 🙂

It happens at times to talk with some customers, thinking about the possibility to save the backups of their VMs right into the same SAN where they are used to execute them. If in the past the usage of tapes for backup purposes have kept away customers from these weird ideas, since the total difference between the two media types, with the rise of virtualizazion infrastructures and their disk-based backups, someone has started to make some confusion… Surely the media for production and backup is the same (disk), and in my opinion this is the origin of the error.

So, in an attempt to explain why saving backups inside the same SAN we are protecting is a HUGE error, here are some reasons why:

– data availability: that’s the main reason, enough by itself to destroy the idea of saving backups inside the SAN. If we do so, and the SAN is no more available (a crash, a break in one of its components, whatever) we do not have at hand both the production data AND their backup copies to start the restore activities. This concept is so clear, still it happens often people think about using the SAN for backups since it’s reliable, redundant, always available. At the end, like every hardware and software component, even SANs can break!

– Performances: with all the differences based on vendors, models, disk types, architectures, in general to save backups inside the production SAN equals at least to double the I/O on the storage processors. First you have the I/O to read production data in order to save them, then you add the I/O to save the backup copies. And if we use more advanced technologies (like for examples Veeam’s Reverse Incremental) the amount of I/O increases even more. Thus leads at the end to longer backup windows, and a worsening of RPO during backup, and RTO during restores.

– Costs: SAN storage is usually a precious disk space: SAS disks, FC disks and lately SSDs are not cheap, and anyway storage vendors ask for high prices for these disks, more than their original price. Thus, wasting this precious space to save backups is a disadvantageous move from a financial standpoint. Even if this space exceeds because the SAN has been oversized… better to use money in a different and distinct storage, and better designed for the I/O patterns required by backup activities.

So, at the end, follow this advice from me and Egon, don’t cross the streams!

Don't cross the streams