SAN vs NAS

SAN VS NAS

I recently built and implemented a VTL (Virtual Tape Library). Database backup files were placed on a disk drive. Those files were continuously copied to tape, retained on-site until the next weekly tape pickup, and they were then moved off-site. Another team dealt with the tape copies, off-site moves, etc. That left me to deal with the disk portion, and that’s all my software addressed. It would make full backups, incremental/differential backups, and transaction log backups to disk based on a schedule. Retention of each type of backup is configurable for each server. Restores are always from disk. If the disk backups have aged past the retention period, or were otherwise corrupted, tapes would need to be recalled on-site and restored to the VTL directory… in essence staging those files for the database restore. It’s a very reliable and inexpensive backup method… but what does all that have to do with SAN VS NAS?

I was recently at the Percona Live 2015 conference talking about the process. The subject turned toward the type of disk storage used. Looking at the pros & cons of each type of shared storage was pretty easy for this specific applications. As we were discussing pros and cons of each, one guy asked what the difference was between SAN and SAS. Everyone had their own opinion that went above and beyond the basic difference. Things like SAN is more expensive than NAS. NAS is slower. Both of those are not necessarily true. So, what is the difference between SAN and NAS?

SAN stands for Storage Area Network. NAS stands for Network Attached Storage. That really does not help much; I added it for completeness. The core difference between SAN and NAS is SAN uses block level protocols to access the data, whereas NAS uses file level protocols to access the data. One can think of it in a MS Windows(tm) desktop environment as Shares are similar to NAS and Drives are similar to SAN (although the physical storage is external to the desktop). Also note, the storage can be a hybrid. For example, the open source product: openfiler This device will function with many file and/or block level protocols. Try to deduce the difference between SAN and NAS protocols from their Products page (tab) 🙂 SAN seems to be talked about explicitly, but NAS information is mostly implied.

So, which makes more sense for the VTL: SAN or NAS? I vote for NAS as the only storage operations are file-save/write, file-sequential-read, and file-delete. If we were talking a storage container for a database engine, I’d suggest that SAN would be more appropriate as the file is read & written at the block level.

Troy Frericks.
blog 12-May-2016
=
Copyright 2015-2016 by Troy Frericks, http://dba.frericks.us/.
#

IS TDE WORTH THE EFFORT

Transparent Data Encryption (TDE) is an encryption method that encrypts database containers (usually a file) of Oracle or SQL Server databases. Containers are “data at rest” (ie, the data is not moving from one place to another). Because database backup programs copy blocks from the (encrypted) database container, TDE causes backups to be encrypted. This is important because backups are frequently moved off-site. If a backup tape/disk were to be lost, any attempt to restore the database would require the keys/certificates that were used to encrypt the data. Without them, the database would not be usable. It’d look like random bits & bites. The engine probably would not even mount the container.

Another feature of TDE is that if a disk becomes unusable, it can simply be discarded. There is no need to destroy the disk if it only contained database containers as any data that might later be recovered would be encrypted.

TDE is “transparent” because it does not change the way the database is used by applications. A SELECT will return data just as it would if TDE were not implemented. Everything works the same. This means that, with TDE, confidential information can be queried (ie, by a DBA), but could not be obtained if a backup tape were restored to another system (assuming it did not have copies of the proper keys & certificates).

When evaluating how to protect confidential information, one needs to carefully consider the goals of the encryption. For example, if you want to protect against this situation: “If an intruder circumvents other security controls and gains access to encrypted data, without the proper cryptography keys, the data is unreadable and unusable to that person” [PCI 3.1, Summary of Section 3], maybe End to End Public Key cryptography should be used (in addition to, or) rather than TDE. Another option might be columnar encryption. Judging by the chatter on the internet, a PCI audit has been blessed because the auditors are simply unaware of what TDE really is. I’ll talk about columnar and End to End Public Key encryption in the near future.

Is TDE worth the Effort? I assert not. Here’s why. If the disk fails, simply destroy it by dropping it on a concrete floor until you hear little pieces of what sounds like broken glass rattling around inside. If you are concerned about backups, simply encrypt the backups as they are taken. Adding a script to do that is much simpler than the hassles of setting up, maintaining, and using TDE.

Setting up TDE involves creating certificates & keys, and understanding how each works.

Maintaining TDE involves things like regularly backing up those certificates & keys and storing them separately from your normal backups (in PCI environments, implementing proper key management).

So, what is involved with USING TDE? If you’ve implemented TDE, the database just works, correct? Yes, that’s what’s cool about TDE… But, suppose you want to perform DBA level tasks like coping a (sanitized) database from production (with TDE) to development?

The process should be: restore the database to production server with a new name, sanitize the new database, back it up, restore it to development. But, with TDE on the source database, the restore will not work unless you have the keys available. I flat-out could not get it to work. Here’s a second opinion. See the bottom of the page, section “Known Issue with TDE”: second opinion.

I ended up having to move keys to the destination system in order to restore the non-encrypted database backup. It’s simply not worth the hassle for zero benefit (other than to say that your database is encrypted, and maybe snow your PCI auditor into believing your data is secure against commonly known attacks, which it’s not. I’ll blog about that next month).

On the other hand, if TDE were not involved, but the backup is explicitly encrypted, one could specify the key when restoring the copy to production, and skip the encryption when backing up the copy… without the possibility of leaving TDE keys behind on development as no keys would be required to restore the unencrypted backup.

Because the problems that are solved with TDE are so easily solved by other means, and because of the problems CAUSED by TDE, I discourage its use.

Troy Frericks.
blog 13-Nov-2015
updated 17-Feb-2016, 7-Mar-2016
=
Copyright 2015 by Troy Frericks, http://dba.frericks.us/.
#