It's a good idea to check that the server_name column of msdb.dbo.backupset matches the server you are checking.

When you do a restore, if the backup set being restored isn't already in msdb.dbo.backupset, an entry will be created for it. This will be constructed based on the backup file's header and will have the name of the server and database that was actually backed up and the backup date. There will be a restorehistory record that references this backupset record, and will reflect the database that was restored to (possibly with a different name) and the restore date.

There are also some GUIDs and LSNs in a table called master.sys.database_recovery_status which can be compared with msdb.dbo.backupset to check if a backup set actually corresponds with the current database with the same name. Look in BOL under "Recovery Forks" for an explanation of what these mean.

If you do a restore, you typically should do a full backup right away. However, without some of this additional checking in msdb.dbo.backupset queries, it's easy to mistake the restore for a backup.