There is nothing particularly magical about the files in the repository; for the most part it is possible to back them up just like any other files. However, there are a few issues to consider.
The first is that to be paranoid, one should either not use cvsnt during the backup, or have the backup program lock cvsnt while doing the backup. To not use cvsnt, you might forbid logins to machines which can access the repository, turn off your cvsnt server, or similar mechanisms. The details would depend on your operating system and how you have cvsnt set up. To lock cvsnt, you would create #cvs.rfl locks in each repository directory. See the section called “Several developers simultaneously attempting to run CVS”, for more on cvsnt locks. Having said all this, if you just back up without any of these precautions, the results are unlikely to be particularly dire. Restoring from backup, the repository might be in an inconsistent state, but this would not be particularly hard to fix manually.
When you restore a repository from backup, assuming that changes in the repository were made after the time of the backup, working directories which were not affected by the failure may refer to revisions which no longer exist in the repository. Trying to run cvsnt in such directories will typically produce an error message. One way to get those changes back into the repository is as follows:
Get a new working directory.
Copy the files from the working directory from before the failure over to the new working directory (do not copy the contents of the CVS directories, of course).
Working in the new working directory, use commands such as cvs update and cvs diff to figure out what has changed, and then when you are ready, commit the changes into the repository.