/var/discourse ディレクトリを単に「tar 化」して別のマシンへ移動し、untar して Discourse アプリを起動することはできません。
主な理由の一つは、Discourse をビルド/ブートストラップする際、（私の記憶ではランチャーが）基本となる Discourse コンテナ（イメージ）が存在するか確認し、存在しない場合は基本となる Discourse Docker イメージをプルして、そのイメージをコンテナとして起動する点です。
その後の基本 git プルにより、ビルドプロセスは別の Docker イメージ（アプリ）を構築します。
これらの 2 つの Docker イメージ（基本イメージとアプリイメージ）は /var/discourse 内には存在しないため、/var/discourse を tar 化しても部分的な「解決策」（この用語を緩く使っています）に過ぎません。
これらの Discourse Docker イメージは Docker イメージとして構築され、Docker の一部として扱われます。それらは /var/discourse に「存在」するのではなく、そこで構築された後に Docker イメージとして Docker へ移動されます。
コンテナの yml ファイルを編集してゼロから再構築することも可能かもしれませんが、より一般的な方法は、以下のファイルを保存することです。
- コンテナの yml ファイル
- アップロードを含む完全なバックアップ
その後、コンテナの yml ファイルを編集し、discourse-docker リポジトリをクローンして再構築します。
そして、コマンドライン（コンテナ内）からアップロードを含む完全なバックアップを復元します。
リポジトリとして GitHub を使用する方法は、古い「unix 的」な「全体を tar 化」して「全体を別のサーバーへ移動」する方法よりもクリーンな解決策です。ただし、この「古い unix 方式」でも、システム内の共有ライブラリ、共有ライブラリのユーザーディレクトリ、配布ディレクトリに含まれないファイル、ディストリビューションのルートディレクトリにない etc ファイルなどがあるため、完全な解決策とならないことがよくあります。
したがって、最新の Linux システムでも、リポジトリをプルするために apt（Ubuntu の場合など）を使用します。Discourse Docker の場合は、基本コンテナを設定するために discourse-docker をプル（およびビルド）し、アプリを構築するために別の discourse リポジトリを使用します。つまり、/var/discourse は（イメージを構築する）「構築場所」と、（データ、バックアップ、公開静的ファイルなど）を共有する「共有場所」です。
この要約が少しでもお役に立てば幸いです。