| || |
Greetings everyone. I’ve been perusing these forums for a while now, and am absolutely astounded as to the wealth of information contained within, however, I have been unable to get pointed in the right direction through reading and searching.
I was recently hired as a part time QA employee for a small research group at a state university, and my first task has been to verify the reliability and validity of our current backup system (NetVault) and to asses whether or not the backups are functioning properly, and whether or not they can be trusted in the event of a catastrophic failure. Apparently, prior to my hiring, such a failure occurred, and they weren’t sure that the backups would cover the problem sufficiently – they got lucky, but don’t want to rely on luck in the future.
At the current moment the plan is to setup one of our servers to have both web and db server capabilities. Then, once NetVault completes one of its once weekly full backups, all of the data (web stuff, and db stuff) will be “restored” to the test server and configured to run almost as a clone of the machine we are currently testing for. After that completes we’ll then have something in place to compare the data from the live servers to the data contained on the backup test server. Right now, I’m thinking something rudimentary in terms of shell scripting, but I’m not sure that is the best option and am looking to explore alternative options.
I feel that this form of testing diverges from the forms of testing contained within these forums, but I would love nothing more than to be wrong about that and to have merely glanced over the proper forum for this kind of testing. A lot of the scripting techniques would be new to me, but I am more than motivated to learn something new, and my employer is aware that I am treading new ground for not only myself, but the company as well.
So, any good prods in the right direction would be greatly appreciated! Thanks.
Re: Testing/Comparing Backups
Welcome to the forums!
Reading your requirements for the test, it does seem thats shell scripting is an option. The database specifically is going to have to entail a list of SQL statement for comparison (if anything just the number of records returned from the tables to match the expected, if not a full blown comparison script).
Focusing on the database to begin with, you can construct the SQL statements you need to run to confirm the db information is correct (and this is a level of comfort you need to define. Some places the number of rows will be enough, others all the table information is required for a comfortable level). There are some tools all ready out there you might be able to use. One of them is csvdiff.pl which is written in PERL. If you can push your db information out to a csv file, you can compare the new to the old (actual to expected) and ensure the information is correct.
For the file system. If there are specific folder structures you need to confirm, there is a tool called InCrtl5 (you can do a google search and find it - it is free so don't get duped into a site that requires you to pay for it to be downloaded, just keep looking). This tool will take information in folders, files, and the registry and capture them into a file for later comparison. Once you have completed your restore work, run it to compare to the previous state and it will report on any differences. You will have to work a little to construct the items for it to look for against your "comfort" level, but it can be done very easily I would think.
It is a good test if the management is not sure of the system, and if you construct it well enough and then maintain it, it is something which can be used in a Disaster Recovery test in the future.
A thought related to the scripting...If QA/QC is something you would like to continue in the future, taking the time to learn any of them is a plus. If you have a programming background then any will do. If you are new to programming, then some time reading and learning on the basic of logic would be needed prior (well, not needed, but a BIG plus if you want to learn it correctly). Any of the free language you can find on the internet are good starts - PYTHON, PERL, etc.
The one thing I will say is to remember that if you tread into the automation arena, a basic understanding of testing techniques and procedures is far more important than understanding the language you are using. The language is a mean to the ends, and definitely not the "reason" for it all.
Good luck and hope to see you back sharing as well as expanding your information in the future!
Insanity: doing the same thing over and over again and expecting different results
Re: Testing/Comparing Backups
Tony, Thanks! At the moment I would say that I am familiar with a few different languages. I've taken a couple C++ classes during the beginning part of my college career, and I spent last summer as a web developer and as such I learned a great deal of PHP and SQL. I wouldn't go so far as to say I'm particularly astounding with any particular language, but I can work out the logic of others' code and am capable of holding my own in most situations. That's honestly why I was hired as a QA early in January, and despite the position being very loosely defined, I'm getting into my groove with the system here, and hopefully proving my worth.
This is an excellent, in my mind, point for me to learn some shell scripting languages. Again, this is something I've wanted to do but had no real drive to do so; now I have that drive.
I appreciate the suggestions of specific tools, and its given me a direction to investigate while I'm getting the testing server setup and running. Thank you very much.