The backups may not br good...or are they not good?
If you don't know, you should test the created backup by importing it on a different SQL2008 Express DB server (a VM is helpful in this case) and test the data being served up by the new SQL DB.
Assuming you have an application that works with this exported data, you could use the same application to verify the data coming from the new DB.
Don't trust a backup you make, verify that it works...else you won't have made a backup at all. It won't matter if you make a backup using 3rd party software or the integrated tools from MS itself. Never trust the message saying "Backup successfully completed". You will be burnt if you won't verify by importing the data again. I have seen the aftermath of others failing miserably with this years ago and you won't see me make their mistakes ever again.
Once you have such a test setup and backup strategy, you will be better prepared for any mishap that is waiting for you. If you do not verify your backups, you have not made backups. Can't say this often enough.
Making a copy of an existing dump you created earlier isn't much of a safety net either. The NTFS file system (or FAT32 or EXT2 or EXT3 or EXT4 or HFS) can't be trusted 100%. Especially folks that use the MS default file size notation of KB/MB/GB are fooled into thinking that copies of a file are the same. This notation introduces rounding and that can (and shall) be fatal. I use the byte size notation in directory opus as first indicator to see if there are file size differences. And I have seen these occur. And I have lost control files from Oracle database, simply because of a 1 byte difference in file size.
For most intends and purposes any of the main file systems are more than adequate, but 100% reliable they aren't.