回答にはなっていませんが.....

バックアップは、その時々の状況によってやり方も異なってくるのでしょうから、
下記のようなページを参照しながら、勉強して行くことをお薦めします。
https://eng-entrance.com/linux-backup#dumprestore

kinme による投稿:

システムが起動しない、何とか起動しているが特定の処理ができない、などいろいろなケースがあると思われます。

　
1)　個々のファイルが認識出来るtarから復旧するなら問題のファイルだけを上書きする
　
・システムが起動しない＝ブート&スタートアップ出来ない
・特定の処理や機能が動かない＝ブート&スタートアップするけど特定のサーバー(例:apache)が動かない
　
いずれの場合でも問題があるのは一部のファイルであってそれらが壊れた/不整合を起こしたなど局所的・限定的だと思います。
その場合にtarのバックアップから復旧する(=特定のバックアップ時点に戻す)としたら、以下のいずれかだと思います。
・壊れた/不整合を起こしたファイルを特定してそのファイルだけを上書き復元する
・壊れた/不整合を起こしたファイルが存在するディレクトリ単位で上書き復元する(ファイル間の整合性が崩れないように１セットで復元する)
　
　
2)　システムが起動しない時のリストア(復元)ならディスクイメージのパックアップからリストアを行う
　
tarで / 配下をまるごとバックアップを取っておいて、システムが起動しなくなった時に、復元作業用にＤＶＤブートするなり別のハードディスクからブートするなりして、バックアップしておいたtarから / 配下を全て上書き復元することは出来ないわけではありません。
( Tar によるフルシステムバックアップ )
　
ただ、バックアップ対象のシステムがパーティションを分けていなかった場合はまだいいのですが、パーティションを分けていた場合、単純にtarから / 配下を展開して上書きするだけでは、マウントポイント(/mnt)にマウントした一つのパーティション配下に全部復元されてしまいます。
そのため、例えば次のようにパーティション分割していた場合だと、/dev/sda5を、復元作業用にブートしたシステムの/mnt[1]にマウントした後、それ以外のパーティションをそれぞれ対応するマウントポイントへ [2]〜[5]というようにマウントしてファイルシステムの階層を仮組みした後で、tarから/mnt配下に上書き復元する必要があります。
/dev/sda1　　/boot　　→　/mnt/boot　[2]
/dev/sda2　　(swap)
/dev/sda5　　/　　　　→　/mnt 　　　   [1]
/dev/sda6　　/usr 　　 →　/mnt/usr 　   [3]
/dev/sda7　　/var 　　 →　/mnt/var 　   [4]
/dev/sda8　　/home　  →　/mnt/home　[5]
(※ sda2とsda5の間で番号が飛ぶのは拡張パーティションを使った場合を想定してるからです)
　
tarで / 配下を全部バックアップを取ってリストアするのは、このような手間と煩雑さがあります。
もしtarのバックアップからリストアするとしたら、パーティションに対応するディレクトリ毎にバックアップを取っておいて、その単位でリストアしたほうがする方がまだ楽だと思います(もしくはddでパーティション単位のイメージをバックアップしておいてそれをリストアするのも方法として出来ます)。
逆に本当に「システムまるごとバックアップ・リストア」を意図するなら、ddで/dev/sdaをディスク全体のイメージでバックアップしておいてリストアが相応しいと思います。
　
また、ddで/dev/sdaのディスク全体イメージをバックアップしておく、tarで / 配下を全部バックアップをしておく、いずれの場合でもそれらからのリストア(復元)はシステム全体がバックアップ取得時点に戻ります。
つまり次のようなことが起きます。
・user(/etc/passwd)とgroup(/etc/group)が、バックアップ取得時点に戻る(＝バックアップ以降に追加したuserとgroupが消える)
・sambaのサーバーを動かしていた場合、そのユーザー登録もバックアップ取得時点に戻る
・DBを使っていた場合、テーブル構造やレコードの状態がバックアップ取得時点に戻る
・/home配下のユーザーのホームディレクトリ上でバックアップ以降にユーザーが作成していたファイルが消える
このようなことを起こすリストア(復元)は「大雑把で乱暴」且つ「手詰まりの場合の最後の手段」であってそうそうあっては困るしまず実行しないと思います。
仮に実行する場合でも、前述のようにパーティション単位またはそれに対応するディレクトリ単位でバックアップを取得しておいて、リストアする部分/しない部分を調整出来る形にすると思います。
　

kinme による投稿:

分からないのは、パーティションを切りなおしてリストアするのか、単に上書きすればよいのか不明です。

tarのバックアップからリストアするのであれば、ファイル単位で書き戻す形になりますから、前述のようにバックアップ時点と同様のパーティション分割がされていて、ファイルシステムの階層(ディレクトリ構造)も出来上がっていることが前提です。
　
ddで /dev/sda を対象としてディスク全体をバックアップしていた場合、その中にはMBRやパーティションテーブルも含まれていますので、リストア先にパーティション構造は不要です。分割しておいても構いませんがリストアが完了した時点で、バックアップを取った時のパーティション構造になってしまいます。
ddで /dev/sdaN の単位＝パーティション単位でバックアップしていた場合は、リストア時もパーティション単位ですから、リストア先となるパーティション構造があることが前提です。
dump/restoreはファイルシステム単位のバックアップであり、パーティションを超えてディスク全体のバックアップは取得出来ません。従って、(ファイル限定しなければ)パーティション単位のリストアになるので、リストア先となるパーティション構造があることが前提です。
　
　
3)　特定の処理・機能(特定のサーバープログラム)に関するtarバックアップファイルは複数になる
　
特定の処理・機能(特定のサーバープログラム)のリストアを目的として、それに関する情報だけをtarでバックアップしておく場合があります。
その場合のtarバックアップは、概ね以下の三本を取得する必要があります。
a)プログラム本体
b)設定ファイル
c)データファイル
　
なぜ分かれるかというと、３つが１つのディレクトリ配下にまとまっていないからです。
例えば、apachだと(当方が知ってる範囲でも)下記のように分かれています。
a)　/usr/sbin/apache2 /usr/lib/apache2 /usr/share/apache2
b)　/etc/apache2
c)　/var/www/html
MySQLだと下記のようになります。
a)　/usr/bin/mysql /usr/lib/mysql /usr/share/mysql
b)　/etc/mysql
c)　/var/lib/mysql
　
a)に関してtarでアーカイブしてバックアップして復元に使うことは、以下の理由であまりありません。
・対象のプログラムから使っている共有ライブラリがこれ以外の場所に存在する可能性がありその所在の把握が難しくtarの対象に含めることが困難である
・仮に把握出来てtarに含められたとしても、単純に復元すると共有ライブラリの世代戻りを起こして、その共有ライブラリを使っている他のプログラムが動かなくなる可能性がある
この辺を回避するためには、a)をtarでバックアップしておいて復元するより、dpkgやaptのパッケージ管理にまかせて依存関係含めて管理したほうが楽であり確実です。
つまり、a)を復元する場合はtarからでなく、一旦対象のプログラムをアンインストールしてdpkgやaptでパッケージを再インストールするということです。
　
b)やc)は、特定の処理・機能(特定のサーバーブログラム)は動いているが、その中で特定の動作や一部分がおかしい……apacheなら特定の仮想サイトが動かない、MySQLなら特定のDBインスタンスが使えないといった場合に、それだけを対象に復元するためにtarでバックアップを取っておきます。
問題がある仮想サイトやDBインスタンスがあったら、その設定をバックアップのものと比較して不具合を見つけて修正するか、最悪その設定(またはデータ)だけをバックアップから復元上書きする形が採れます。
また、a)をパッケージ管理にまかせると再インストールの際に設定ファイルやデータファイルが初期化される場合もあるので、b)やc)を使って再インストール前の設定状態・データ状態に戻すことにも使えます。
　
いずれの場合でも、設定やデータを復元したからといって即時に反映はされないので、サーバーの場合はsystemctlコマンドでserviceを再起動する必要があります。
　
　
4)　バックアップ取得はシステム稼動が低い時、またはシステムを停止して実施する
　
当方の誤解かも知れませんが、質問者の方はバックアップ取得を対象のシステムが稼働状態(オンライン)で実行しようと考えられているように思えます。
もしそうなら、そのようなバックアップは出来ないことではないのですが、バックアップ結果に不整合が起きる可能性があります。
例えば、/ 配下全部をtarでバックアップするのに２時間かかるとします。そうすると２時間の最初のほうで参照されtarに書き込まれるファイルと、２時間の最後のほうで書き込まれるファイルが出てきます。
これらが全く無関係のファイル同士ならいいのですが、中には相互に同期していて整合性を保っていないとならないものもあります。
稼働中の状態でバックアップを取ると、２つのファイルの先のファイルがtarに書き込まれた後で、後のファイルに変更に加わりその後でtarに書き込まれることが有り得るので、２つのファイルの間の整合性を崩してしまいます。
　
このようなリスクを回避するため、バックアップの取得は、夜間の稼働が低い時に行ったり、場合によってはシングルユーザーモードにして行います。
理想的にはシステム自体を停止して、ＤＶＤブートや別のハードディスクからブートして、バックアップ対象を単なるデータディスクの状態にしてバックアップ取得します。
（※これは飽くまでシステムバックアップやサーバーバックアップの場合の話であって、自分のホームディレクトリにある特定のディレクトリをtarでアーカイブするような局所的or小規模な場合には考慮する必要はありません）
　
　
以上です。