A few questions immediately come to mind for things which might affect performance (although I would not expect things to slow to that degree): Is the database file on a local disk for where the application is running, or is it accessed over a network share? Is the access mode (Open Mode) NonExclusive* or Exclusive* (or SharedReadOnly)? Does the table use any "(MAX)" types (or Image, Text, or NText)? What is the "page size" of the database file, and does the table contain any fields often containing data near or beyond that size (eg. VarChar or NVarChar with strings over 2000 characters long)?

Also, external effects should be checked on and ruled out: What is the memory load and limit on the machine (eg. from Task Manager's Performance tab), and what is the memory usage level for the application process (while running the backup)? When the application is running the backup, what is the CPU usage for the process and for the overall system? (And are any other processes using up a lot themselves?) What is the CPU usage for Visual Studio? Is it running extensions such as ReSharper which can sometimes use a lot of cycles when rescanning files?

For anyone else finding this thread, we were also working this issue via a ticket.  The particular performance issue turned out to be due to a large table not having the indexes it was expected to have--it's not clear how it ended up that way--resulting in un-optimized scanning of a large table when targeting single rows (and so on).

Query structure and what indexes are available can have a significant impact on performance in some cases--especially as the database scales up.  Joins and sub-queries can also have a multiplicative effect on query time if not structured carefully.