Review: Symantec/Veritas System Recovery 4kn compatability WTF-- no, seriously, WHAT THE F*(K

Phas3L0ck · January 11, 2019

I've just figured out one of the DUMBEST software design flaws I have ever seen IN MY LIFE! ~Way to go M1cr0$0ft, add another way you've made your OS user UN-FRIENDLY to the growing pile of mistakes.

For those of you who are data-hoarders or archiving gearheads and are very backup-conscious, you might have at least heard of the surprisingly user-centric backup software Veritas System Recovery or VSR, (also formerly Symantec System Recovery or SSR) perhaps the simplest, most efficient way to backup and recover your entire hard drive as a central disk image.

After struggling with getting the bootable recovery disc to work due to my system's poorly coded BIOS/firmware (live boot WinPE doesn't work with a GPU installed) and having to rebuild my OS from scratch just to get the native installation of the System Recovery program working, I was able to restore my original OS image to a spare disk I had on hand. This coupled with the fact that the bootable disc is built with very problematic Windows 8 & 10 ADK rather than the more mature and functional Windows 7 AIK does not bode well for this program's data recovery ability. But if you're a normal, uninformed joe doing a normal boot or running this sort of thing on a normal system and not doing anything special, I guess it works just fine. I would have used Backup Exec, but there isn't much available for a bootable recovery disc. VSR is best for OS backup and recovery and has a reasonable boot environment, but most of all it was a step up in integration and backup automation from the previous software I used. With VSR and SSR, it's easier to continuously create granular snapshots of the system so that a more recent restore point will be available when needed, whereas the old way was to take one static disk image and replace the old one every few months...

Now that my system was fully restored, it was time again to run updates, and I had a new drive to add; a brand new Seagate 6TB SAS 4kn SED (ST6000NM0205) enterprise drive that I got as the first piece of my planned RAID array (1 drive down, 7 to go) and to determine the usefulness of the secure features. Really all I cared about was a 6TB 4kn generic drive, and this was the cheapest option above all others (likely since it was resold by someone who got it from an OEM) which just happened to be an SAS model, which is perfect if I decide to actually make a RAID array with it. I don't particularly care for OEM drives due to their lack of support and the known abnormal failure rates of some models, but like I said it is 6TB and having the SED feature (although I'd prefer FIPS, but not sure what difference it makes) I figured it would make a great eval drive to see what it can do with SED and whether or not a better SED drive would be worth investing in (it's not really, most are OEM so it has no warranty for replacements and it has some weird issues-- check my previous thread for details)...

So updates are finished, I cleared all the junk files out and defragged the OS drive, and it's time to update my disk image.

Note: at this time I only have 2 drives in my server for construction and validation; (I'm still building the thing) the ST6000NM0205 connected to an LSI 9311, and a generic 1TB SATA drive on the internal intel PCH.

I started the backup process and just as the progress screen starts to show that it's running, it presents and error message saying that VSS has failed for some reason! I tried everything I could possibly think of to fix the problem; everything from SFC, chkdsk, and re-registering the VSS components and multiple restarts as far as to trying the backup with another drive on the native PCH thinking the SAS adapter isn't fully compatible (which shouldn't happen) and still nothing works! I heard rumors about incompatibility with 4kn drives, but that was when they were just being released after some of the first AF drives were developed, and most of those problems have been solved in ALL systems as far back as Vista SP2-- so Win 7 SP1 and everything newer became native to the... native... 4kn format. So I did some digging and read some vague compatibility issues with native 4k drives and SSR 2013-- but that was long before the version I use of VSR 18. I decided to downgrade to the older SSR 2013 R2 which is still listed as compatible with 4kn, as any version of SSR after the now legacy 2013 (pre-R2, the last version to work on Windows XP, no wonder it doesn't do 4kn) should work just as well as the new VSR, and has only a slightly different codebase.

After a thorough uninstall of VSR 18 and a proper fresh install of SSR 2013 R2, I ran the backup again and still had the same problem! I still questioned some of the vague comments and odd solutions I read, and I wanted to see if it would make any difference if I changed something about the new ST6000NM0205 drive... I deleted the partition and basically emptied it, but the backup (going to another SATA drive on the PCH) still didn't work... so, going out on a limb, I physically removed the drive in the extremely unlikely chance that that would make a difference. I ran the backup again and IT WORKED!!! So a backup program recently made fully compatible with 4kn drives works perfectly without the drive being present, WHAT THE F***?!? Curious and confused, I reinserted the drive during the backup and there was no interruption... interesting... after the backup finishes, thinking the issue was finally fixed, I ran the backup again pointed at the new 6TB 4kn drive... AND IT DOESN'T WORK! I'm at my wit's end trying to figure out what the h3ll is going on, but there's one more thing I haven't tried yet because it's completely idiotic; the only other solution being spun around is people who say to reset shadow copies on the drive being backed up, and that having the VSS service enabled isn't enough. I re-activated shadow copies on my OS drive at the absolute lowest size (about 320MB) and set it to not even attempt to run except at startup, to avoid having junk on my drive during operation. Without bothering to restart, I hit the button to try the backup to my new drive one last time while being bored half to sleep by this quizzical quark, and this time, IT WORKS. What... The... F~~AAAAAAAAAAAAAAAAAAAAACK~~?!?

To summarize, SSR 2013 R2 and VSR only work with 4k drives present in the system if the legacy shadow copies feature is enabled (even at the lowest settings) on the drive being backed up, or with shadow copies totally disabled (except VSS service being enabled) SSR and VSR only work with drives of 512n, 512e, and 1k cluster sizes, without the presence of 4k drives of any kind... yeah... I'm gonna go slam my head in the door now. (not really, don't worry)

Long story short, if a 4kn native drive is even present in the system, and you disabled shadow copies on the drive you're backing up, (but VSS is still active) System Recovery just won't work! I've seen a lot of freakishly weird errors, quirks, and quarks over the years, some of which took me literally forever to solve, but this one takes the cake. Not because it took a long time to figure out, but because it's so unbelievably STUPID... seriously, why do we even have VSS anymore? VSS was made primarily for Windows' obsolete built-in backup feature that no intelligent person would ever use!

I think we can agree that a huge software company's reliance on mechanisms provided by Microsoft to make their program work is downright retarded-- and I say this with close attention to the definition of the word straight from the dictionary, like so; Symantec and Veritas, while they have succeeded in developing a useful tool for data recovery, lack the ability to comprehend the shortcomings of the components and mechanisms of any kind made by Microsoft nor the impact that has as a direct result of their decision to use those components to simplify program development for them. This speaks to a lapse in creativity and what seems like an inability (or poor decision making) to create mechanisms of their own along with their System Recovery backup program that would be superior to VSS. Visible as a result is the following of a trend, not the making of progress. That, my friends, is almost the very definition of "retarded," a slowness or limitation in intellectual understanding and awareness, academic or other progress.

Franck · January 11, 2019

So i'm not the only one that had the "pleasure" to deal with Veritas. My case screwed up SQL database backup for over a year plus corrupted a bunch of encrypted drive that went totally unusable. Long live VM snapshot with good old copy pasted backup now.

Phas3L0ck · January 12, 2019

11 hours ago, Franck said:

So i'm not the only one that had the "pleasure" to deal with Veritas. My case screwed up SQL database backup for over a year plus corrupted a bunch of encrypted drive that went totally unusable. Long live VM snapshot with good old copy pasted backup now.

I'll raise my glass to that.

For SQL, the best way to go is either Backup Exec or NBU. If those don't work, either try Acronis or program your SQL instance to automatically make a live clone of the databases to another drive if that's possible. In the case of SQL, not even a massive RAID-1 array of upper-class SSD drives with hot spares is enough, that's why most servers will have a failover cluster option to clone the active server in live operation. From what I hear today failover clustering is extremely rare, difficult, and very expensive, but highly effective if done properly.

Encryption is a different story; anyone with experience would know it's simply not worth the effort to even attempt to backup encrypted media, not to mention the security risks and complications that defeat the entire purpose of having encryption in the first place. Backup images themselves can be encrypted, but the imaging only works if the source is unencrypted. You might try backing up encrypted virtual drives, but again there will only be more problems so what's the point?...

This is actually a problem for me right now as I'm trying to draw up a secure, reliable storage architecture for the server I'm building. As far as security, there are 2 options; either encrypt the data and hope that RAID will be enough to keep it alive (the IT industry frowns upon this) or store the data without security (though the backup images can be encrypted) and be able to make plenty of backups while taking the extreme risk of data leakage, a common practice that 99% of the world engages in... no wonder so much personal info was stolen over the years... This is partially why I ordered an SED drive, to test the ability to scrub everything in a moment's notice while I have a fully secure copy in hand that no one would know about and never be able to crack. Even if it did work as intended, it would still be another configuration and location management nightmare.

I'm drafting a balanced implementation of both in which classified information might be either in a secure container or on a different partition of the same volume to allow faster and more efficient use of disk imaging software to work on unclassified data automatically, while classified data would still be transferred by hand. There are enormous flaws in this plan, but on paper it might work in the case that the classified data might be fairly static and rarely change.

VMware snapshots is great for some stuff, but not everything. And I certainly wouldn't use a VDisk for actual data storage in any environment where files cannot be lost. The biggest benefit I draw from backup software is data compression, which makes the entire file history compact and more efficient. Speaking of efficiency, regular copy paste is good, but a major pain in the ass if you don't have the infrastructure to handle that kind of load.