It is not possible to restore a single table from an earlier point in time directly into an existing database.
You can restore all or part of the database as a new database, then copy the required data across. Or, you can restore using the
REPLACE option, but the whole database will be reverted to the earlier point in time, not just the table you are concerned about.
If all your data is stored in the
PRIMARY filegroup (the default), you have no choice but to restore the whole thing. If you have multiple filegroups, you may be able to restore just some of the filegroups, reducing the space needed. The details depend on the database recovery model as well as how any filegroups are arranged, see:
You can determine in advance how much space will be needed for the restore by running the following command and inspecting the output:
The paths to the files that will be written are all from the perspective of the SQL Server instance, not the user performing the restore. You will need to ensure that enough space is available for all the files that will be restored. Note that the size of the file may be larger than the amount of data stored in the file, and larger than the size of the backup file. SQL Server only writes the data actually stored to a backup, which may also be compressed, but a restore must create the full file size.
The process of creating the data files will be much faster if Instant File Initialization is enabled on the restore target.
Backup and restore is a large topic, well covered in the documentation, see:
RESTORE command offers more flexibility and control than using the SQL Server Management Studio UI.
If you have differential and/or transaction log backups as well as a full database backup, you may be able to apply one or more of these to get closer to the point in time when the accidental truncation occurred.