Most restores people need are small: one page edited wrongly, one file deleted, one table emptied by a bad update. Restoring the whole site to fix that throws away every order and comment since the backup - which is usually a bigger loss than the original mistake.

One file from an archive

tar -tzf backup.tar.gz | grep wp-config\ntar -xzf backup.tar.gz -C /tmp/restore path/inside/archive/wp-config.php

Extract to /tmp first, always. Look at it, then copy it into place - extracting straight over the site is how a small restore becomes a large one.

One table from a dump

sed -n '/-- Table structure for table `wp_posts`/,/-- Table structure for table `wp_postmeta`/p' backup.sql > wp_posts.sql
mysql -u user -p dbname < wp_posts.sql

A dump is plain text in table order, so the range between one table header and the next is exactly one table.

Restoring a table drops and recreates it. Anything written to it since the backup is gone - so on a table that is still being written to, restore into a COPY and move the rows you need.
mysql -u user -p dbname_restore < wp_posts.sql\n# then\nINSERT INTO dbname.wp_posts SELECT * FROM dbname_restore.wp_posts WHERE ID = 123;

Know what is in the backup before you need it

tar -tzf backup.tar.gz | head -30\ngrep -c "CREATE TABLE" backup.sql

Two minutes now, once, saves an hour on the day something is wrong - and the day something is wrong is not the day to find out the uploads were never included.

On EGPHP hosting, EGPNL keeps daily backups and restores a single file or a single database from the panel, so none of the above is needed unless you run the server yourself.