Having issues restoring a database in SSMS, error 38. The databases are transferred up to google via their Drive API. Download it on my side and has error. If I transfer it through teamviewer from client PC I still get the same error. Only happening on two clients the rest are fine. I have tried backing up with FORMAT options and WITH CHECKSUM. Both succeed and backup is taking when verifying. I have ran restore fileheaders only and get proper data except the physicalname path has a lowercase 'c' for the drive on the problem databases. I have read this could be a corrupt database but I don't understand how the checksum and verify sql functions pass if so. Any insight would really help. This is the backup command used in C# "BACKUP DATABASE " + database + " TO DISK = '" + database + "_" + dateTime.ToString("yyyy_MM_dd_HH") + "_CloudBackup.bak' WITH NAME = 'database', INIT, CHECKSUM" EDIT: Running

check

on the database produced no errors. I have tried updated the physical name of the .mdf and .ldf it does not work still. Taking a backup from SSMS produces a valid backup file. It has something to do with the services I wrote. EDIT 2: I am restoring through SSMS GUI. I have also tried

RESTORE DATABASE db_name FROM 'backup_path'

Commands

RESTORE VERIFYONLY FROM DISK = 'backup_path'

On both computers, mine and the server PC yields "The backup set on file 1 is valid."

RESTORE FILELISTONLY FROM DISK = 'backup_path'

Have only test on my PC. Returns paths to mdf and ldf, no errors. Both PCs have sql server 2012 (SP1)

I have a dump of a postgis layer (layer.dump), which I am trying to add to my heroku database (mydatabase). The postgis layer is stored on S3 (https://s3.amazonaws.com/layer.dump) . I would like to add the layer to to the heroku database and previously used heroku pgbackups:restore DATABASE 'https://s3.amazonaws.com/layer.dump '. However, the new heroku pg:backups restore 'https://s3.amazonaws.com/layer.dump ' DATABASE deletes all data from the target database before restoring the backup (https://devcenter.heroku.com/articles/heroku-postgres-backups) . Is there still a way to only restore a single table and leave the remaining tables in the database untouched?

I'm taking a backup of a SQL Server 2019 database with CDC enabled, and trying to restore it to a different instance. I don't need CDC on target database so I don't have the "keep_cdc" option in the restore script. Despite this, I'm getting the following error: > Could not upgrade the metadata for database mydbname that is enabled > for Change Data Capture. The failure occurred when executing the > action 'drop function fn_cdc_get_all_changes_'. The > error returned was 3764: 'line 1, state 1, Cannot drop the table > valued function > 'cdc.fn_cdc_get_all_changes_dbo_mytablename' because it is > being used for Change Data Capture.'. Use the action and error to > determine the cause of the failure and resubmit the request. The database seems to restore OK despite the error, but CDC is enabled when I look in sys.databases. When I try to disable cdc on the restored database I get following error: > Could not update the metadata that indicates database mydbname is not enabled for Change Data Capture. The failure occurred when executing the command 'DROP TABLE dbo.systranschemas'. The error returned was 3764: 'Cannot drop the table 'dbo.systranschemas' because it is being used for Change Data Capture.'. Use the action and error to determine the cause of the failure and resubmit the request. Any thoughts as to why this is happening despite the fact that I'm not including keep_CDC in the restore script? Any potential solutions?

My database was just hacked. I tried doing some work and could not log in with the created user credentials. When I checked the database, I saw an intruder was removing the users and had created a replication_user, I tried removing them, and before I could run a backup, the intruder had changed the root password. I have stopped the server, the MySQL server is running in a Docker container, and I have backed up the volume containing all the files, including those in var/lib/mysql. Please, how do I restore it into a new database? The last full backup was from a few days ago

I'm trying to move a Windows SQL Server database from Windows 10 to Linux. For this, I'm following the instructions in https://learn.microsoft.com/es-es/sql/linux/sql-server-linux-migrate-restore-database?view=sql-server-linux-2017 The linux database is freshly installed in an Ubuntu 16.04.4 LTS. The Windows database backup is a previously existing (I have not executed the backup, but it's a full backup) When I try to restore, it generates an error in the catalog database (access denied), as shown (database name changed to 'mydb' for privacy): sqlcmd -S localhost -U SA -Q "RESTORE DATABASE mydb FROM DISK = '/var/opt/mssql/backup/mydb_backup_201804300000.bak' WITH MOVE 'mydb' TO '/var/opt/mssql/data/mydb.mdf', MOVE 'mydb_log' TO '/var/opt/mssql/data/mydb_log.ldf', MOVE 'sysft_appuser_catalog3' TO '/var/opt/mssql/data/catalog.ft'" Msg 7610, Level 16, State 1, Server irulan, Line 1 Acceso denegado a '/var/opt/mssql/data/catalog.ft' o la ruta de acceso no es válida. Msg 3156, Level 16, State 50, Server irulan, Line 1 El archivo 'sysft_appuser_catalog3' no se puede restaurar en '/var/opt/mssql/data/catalog.ft'. Utilice WITH MOVE para identificar una ubicación válida para el archivo. The other 2 files (mdf and ldf) are created without problems in the same folder). I have tried with different file names, creating previously (touch) the file, and so on with no success. How can I restore this database? I'd be willing to restore it without the full-text index - is there a way to do that? This is the output of FILELISTONLY (to check the content of backup) LogicalName PhysicalName Type FileGroupName Size MaxSize FileId CreateLSN DropLSN UniqueId ReadOnlyLSN ReadWriteLSN BackupSizeInBytes SourceBlockSize FileGroupId LogGroupGUID DifferentialBaseLSN DifferentialBaseGUID IsReadOnly IsPresent TDEThumbprint SnapshotUrl -------------------------------------------------------------------------------------------------------------------------------- -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- ---- -------------------------------------------------------------------------------------------------------------------------------- -------------------- -------------------- -------------------- --------------------------- --------------------------- ------------------------------------ --------------------------- --------------------------- -------------------- --------------- ----------- ------------------------------------ --------------------------- ------------------------------------ ---------- --------- ------------------------------------------ ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ mydb D:\Program Files\Microsoft SQL Server\MSSQL.1\MSSQL\Data\mydb.mdf D PRIMARY 3460300800 35184372080640 1 0 0 D64B0490-3FF6-4EFE-A9A1-491B5993F3AF 0 0 2348613632 512 1 NULL 30094000017824000037 B7E468AB-78C2-4732-8D73-2F07E3ABAF9D 0 1 NULL NULL mydb_log D:\Program Files\Microsoft SQL Server\MSSQL.1\MSSQL\Data\mydb_log.ldf L NULL 1540227072 2199023255552 2 0 0 A6B8CF28-C3D8-4B50-B030-4D5B14F82084 0 0 0 512 0 NULL 0 00000000-0000-0000-0000-000000000000 0 1 NULL NULL sysft_appuser_catalog3 D:\Program Files\Microsoft SQL Server\MSSQL.1\MSSQL\FTData\appuser_catalog3 F PRIMARY 931744 0 65539 17974000000690900001 0 0B0AEAB0-86A2-42ED-9B37-E70EE556383C 0 0 983040 512 1 NULL 30094000017824000037 B7E468AB-78C2-4732-8D73-2F07E3ABAF9D 0 1 NULL NULL (3 rows affected) Note: I have found this [Stack Overflow post](https://stackoverflow.com/questions/536182/mssql2005-restore-database-without-restoring-full-text-catalog) ; the poster had a different problem, but was also willing to restore the DB without the full-text data. It doesn't say how (if!) he ever resolved his problem, so it doesn't really give me an answer.

Someone accidentally deleted several records from Cassandra's table in the cluster. I want to restore the last snapshot to another copy table with the same structure within the cluster. What is the best way to do that? Cassandra v4.0.4

I'm trying to import a large (30GB) SQL file (generated using mysqldump) into an RDS instance MySQL 5.7 database, from an EC2 instance on the same VPC. It's importing most without a problem, but missing around 5 tables from the end of the dump. Looking around for related logs in the AWS console I can't really find much of use, all I'm seeing is this:

2021-02-17T12:16:20.168722Z 0 [Note] InnoDB: page_cleaner: 1000ms intended loop took 10360ms. The settings might not be optimal. (flushed=599 and evicted=179, during the time.)
2021-02-17T12:16:36.461195Z 0 [Note] InnoDB: page_cleaner: 1000ms intended loop took 5988ms. The settings might not be optimal. (flushed=490 and evicted=124, during the time.)
2021-02-17T12:16:46.848239Z 0 [Note] InnoDB: page_cleaner: 1000ms intended loop took 6766ms. The settings might not be optimal. (flushed=447 and evicted=0, during the time.)
2021-02-17T12:17:16.371538Z 0 [Note] InnoDB: page_cleaner: 1000ms intended loop took 10380ms. The settings might not be optimal. (flushed=370 and evicted=240, during the time.)
2021-02-17T12:19:22.153786Z 0 [Note] InnoDB: page_cleaner: 1000ms intended loop took 27942ms. The settings might not be optimal. (flushed=299 and evicted=637, during the time.)
2021-02-17T12:21:19.368279Z 0 [Note] InnoDB: page_cleaner: 1000ms intended loop took 16509ms. The settings might not be optimal. (flushed=361 and evicted=136, during the time.)
2021-02-17T12:23:01.420623Z 0 [Note] InnoDB: page_cleaner: 1000ms intended loop took 5097ms. The settings might not be optimal. (flushed=349 and evicted=125, during the time.)
2021-02-17T12:23:16.836488Z 0 [Note] InnoDB: page_cleaner: 1000ms intended loop took 8285ms. The settings might not be optimal. (flushed=307 and evicted=121, during the time.)
2021-02-17T12:23:52.965471Z 0 [Note] InnoDB: page_cleaner: 1000ms intended loop took 19104ms. The settings might not be optimal. (flushed=299 and evicted=607, during the time.)
----------------------- END OF LOG ----------------------

I'm not really sure where to start looking without any logs. Only thing I can think of is maybe lack of memory, but looking at the stats it still had "some" memory left on the RDS instance while it was importing. When I check the file the CREATE TABLE statements are definitely there for the missing tables. Can anyone give any tips on how I can figure out what's going wrong?

Steps I used: 1. mongodump 2. copy dump folder to another computer (for each collection I get .bson and metadata files) 3. mongorestore myDumpFolder I noticed the indexes are lost and _id has new values after mongorestore. Can anyone share their restore experiences that restored both indexes and mongodb_id?

I need to move two databases, WES and WILL from a Win2012/SQL2012 instance to a Win2016/SQL2016 instance for a software upgrade. I'm using the full backup files from the SQL2012 maintenance plans. I've verified I can restore them to the original SQL2012 instance with no errors. Restoring WES to SQL2016 reports no errors, but dbcc checkdb shows errors: >Msg 8939, Level 16, State 98, Line 13 Table error: Object ID 60, index ID 1, partition ID 281474980642816, alloc unit ID 281474980642816 (type In-row data), page (1:453). Test (IS_OFF (BUF_IOERR, pBUF->bstat)) failed. Values are 133129 and -4. ...etc Restoring WILL to SQL2016 stops partway through the upgrade steps with >Database 'WILL' running the upgrade step from version 805 to version 806. Msg 601, Level 12, State 3, Line 2 Could not continue scan with NOLOCK due to data movement. I thought the upgrade between versions was automatic. Is there anything else I need to do?

Yes the databases (source and destination) are the same version. I have checked 3 times. Both are "Microsoft SQL Server 2019 (RTM-CU8-GDR) (KB4583459) - 15.0.4083.2 (X64)" The database itself restores ok without error. Only when I try the read-only file group restore does it give the error. I have redone the back up and attempted the restore again just in case I had something wrong with the backup. I have done this numerous times with ss 2016 and even when upgrading from ss2016 to ss2019. But now I am testing the restores it just looks broken to me. Almost like this is a bug