No, this is not possible.SQL Server 2017 backups cannot be restored by any earlier version of SQL Server ref
Also, regarding detatching and reattaching per the docs:
After being attached to SQL Server 2017, the database is available
immediately and is automatically upgraded. This prevents the database
from being used with an older version of the ...
In addition to what Scott said about the Resource DB — [mssqlsystemresource] — that it's read-only (which is entirely correct; it's SQL Server application data), it needs to be stated that no database "contains information on all objects in its server instance". That concept does not exist in SQL Server: not for [mssqlsystemresource], nor [master]...
Well, reading the documentation for Resource Database (highlighting mine)
The Resource database is a read-only database that contains all the system objects that are included with SQL Server. SQL Server
system objects, such as sys.objects, are physically persisted in the
Resource database, but they logically appear in the sys schema of
The Log file of database is fragmented too much and there are too many Virtual Log Files. This would force recovery to take longer time. Run dbcc loginfo(db_name) on database and tell me how many rows it returns. Please see How a Log file Can affect database restore time
The SQL Server service account does not have "Perform Volume Maintenance Task" privilege ...
As long as you state that you did restore before and it took much less time I would quess that some of the following could be the reason:
some other process on the reporting server taking a lot of resources (in- and outside of SQL Server), that put high load on disks;
slow network connection between backups and reporting server if backups are located on a ...
So I tried to restore only filegroup of filestream to other database, but I get an error message
As Laughing Vergil originally mentioned in a comment, your question is answered in this great Stack Overflow post: Restore filegroup to different database
The gist of the answer is that you always have to start by restoring the database with the PRIMARY ...
To add to Jovanpop's answer, you should still be able to take copy_only backups with TDE turned on if you are using AKV integration i.e. BYOK TDE, as long as your destination instance in other subscription has access to the same encryption key used on source instance.
copy only backups are currently the only solution. Cross subscription pitr and geo restore don't work because currently we cannot verify that initiator has all required permissions both on source and target subscriptions.
We have a database that was basically used for application purposes
but it was using "master" - bad indeed. We created a new database
called school that is now being used (same structure as how master was
minus a table renamed correctly). I was trying to restore a .bak file
from the old db (master from sql 2008) to the new school db (school in
Let's define a couple of variables to make the rest easier to copy/paste (using names from the original question)
The following assumes that your backup was created with the "custom" format like this:
pg_dump -U postgres -F custom $old_db > "$db_dump_file"
To restore $...