|Yes, you definately need to get the different types of backups straight before you proceed.|
The builtin ntbackup should serve your purpose but there are a couple caveats you need to keep in mind.
Open files cannot be backed up. I know for sure the ntbackup will stop if it encounters an open file. So, if you plan on backing up a database you must first figure out how to stop it, so that all files are closed and can be backed up, and then restart it after the backup has run. I know the MS SQL has a built in backup program that does all the above. You simply configure it to run at say 2:00 am and then run the full system backup 30 min's later and include the file generated by SQL in the full system backup.
Also, you said, "If i just copy stuff I'll be able to see what actually gets copied and run tests."
The techonology to do all that is built into ntbackup. To see what's in the file, run the "restore" feature, open the backup file and you can look through the complete backup at any/all files within it. Also, you can restore a single file, multiple files, or if need be, the whole backup.
As to running tests, I know that you can have it double check the data in the backup to ensure it matches what was backed up. But, to be really really sure your backup is working properly, you must setup a test server that exactly duplicates the production server(s) you're backing up and then restore that backup to the test server in order to verify the backup restores correctly. This is an important step that many admin's don't take to their regret. Believe me, it totally sucks to discover your backup is no good when you need it. Better to find that out on a test server, fix the problem and ensure it can be restored before you ever need it (hopefully you never will right!).