September 22, 2015 at 3:08 pm
Have you been able to answer the basic questions yet? They will determine the approach you take.
September 23, 2015 at 8:05 am
+1 on DeWayne_McCallie's answer. I see a few incredibly knowledgeable folks advocating moving or copying the file. However, I know SQL 2012 will back up and restore from network drives.
I personally run scripted jobs that back up my production server to a shared drive from which a development server later restores. Is this a bad approach? What do I lose if I am sure of my backup chain and how my backup file is then backed up?
Thanks folks.
September 23, 2015 at 8:20 am
Mitch C. Stein (9/23/2015)
I know SQL 2012 will back up and restore from network drives.
So will everything from 2005 and up. And, 2005 also had the "COPY ONLY" feature... just not in the GUI. Since the files are on network drives, I don't both SQL Server with making another backup. I let the "lesser" machines do the copy/restore.
--Jeff Moden
Change is inevitable... Change for the better is not.
September 23, 2015 at 8:38 am
Jeff Moden (9/23/2015)
Mitch C. Stein (9/23/2015)
I know SQL 2012 will back up and restore from network drives.So will everything from 2005 and up. And, 2005 also had the "COPY ONLY" feature... just not in the GUI. Since the files are on network drives, I don't both SQL Server with making another backup. I let the "lesser" machines do the copy/restore.
That's what I do.
Veeam controlled backups that are then backed up with the local machine backup.
Independent of this, a copy-only backup to a drive on the development box that has a scripted restore pointed at it.
Viewing 4 posts - 16 through 18 (of 18 total)
You must be logged in to reply to this topic. Login to reply