Greetings to you all
I'm a newbie here and hope I am posting to the correct forum. Please point me in the right direction if not
I have been a Windows server admin for over 25 years, and have had some dabbling's in SQL over the years, but am by no means a SQL admin. I have backed up and restored DB's in the past so my current situation has me somewhat baffled. I had thought that perhaps as a newbie I had done something to lose data through truncated logs or something by making bad decisions on options while performing my back up or the restore.
Here is where I am at. We run Windows based systems and are leveraging Hyper-V for virtualization. We have two physical hosts running which replicate between each other and use VEEAM as our backup technology. We have been experiencing poor performance across the board on applications using SQL and having inherited the entire environment, thought I could do a better job of outfitting a better SQL system. Old system is a Windows 2008R2 server running SQL 2008 of which all installed to the only drive, C:
I spun up a new Windows Server 2012 R2 and installed a number of drives to hopefully increase the performance of the SQL services. I have an OS drive, a TempDB drive, a Logs drive, a SQLDATA drive for the system DB's, a backup drive, an SSD dedicated to page file, and an application drive for the SQL application itself.
I migrated the DB's for all applications over to the new SQL system using the SSMS2008 on the old server to do a FULL backup, copied the .bak file across the network onto the new SQL2012 system, and then ran a restore. This has worked well for all DB's to this point, but I've run into a mystery on this last go around.
In the interest of trying to be thorough, the application backing the issue at hand is Raiser's Edge. It uses an application server in it's architecture which then talks to a SQL backend. Client workstations connect, and get their configuration from the App server. RE states that you need to use their native tools for moving a database, so using the RE management console, you need to "Attach" a database to the RE system. You can't just edit a configuration or "point" the RE application at a SQL instance. This "attach database" process in their management interface is doing a "Restore" in the background, and in the end, at least so I hoped, the application would end up repointed to a freshly restored copy of the DB on this new SQL2012 instance.
Well, it did. It worked wonderfully and seemed quite responsive. Unfortunately I received a call from the end users shortly afterwards telling me I had restored old data and that although it was Jan 18th 2019, the data showing in the application is only up to December 2018. Somehow I'd gone from the RE application in use on the 117th and all days before, to having lost weeks of data.
The database was actively used daily all of this month as it always is, so the transactions must be still on the database on the old SQL2008 system somewhere.
Not sure where to turn while I await a SQL consultant to show up onsite if I can find one on short notice so I'm hopeful some of the kind souls here have a handle on what might be causing such woes
Mystified and exhausted