TimeMachineが使えないので、Kopiaでバックアップすることにした

バックアップ、必要ですよね?

MacにはTimeMachineという大変よくできた仕組みがあります。外付けディスクやNASを指定しておけば、あとは勝手に世代管理してくれます。ところが、自分のMacはMicrosoft Intuneで管理されており、TimeMachineが明示的に無効化されています。また、クリーンインストール、つまりdotfilesで再構築するスタイルなので、TimeMachineによる全体バックアップはそもそも不要です。さらに、ownCloudやOneDriveで管理されているディレクトリ内は、間違って削除してしまった場合でも復旧できるので、これらもバックアップする必要がありません。ターゲットは、ローカルにしか存在しないファイルと、iCloud Driveです。後者はなぜバックアップが必要かというと、リストアに非常に時間がかかって使い勝手が悪いから、です。

TimeMachine以外のバックアップ方法の要件は次の3つです。

  • 重複排除ができること
  • GUIがあること
  • OSSであること

この条件だと、第一候補はKopiaです。Kopiaはスナップショット型のバックアップツールで、重複排除、圧縮、暗号化、世代管理に対応しています。GUIのKopiaUIもあります。

今回は、サーバ側にSFTP専用の保存先を用意し、Mac側からKopiaUIでバックアップする構成にしました。

サーバ側を用意する

バックアップ先は、自宅鯖の 192.168.1.4 です。

保存先は /opt/backup 配下に作りました。

構成は次の通りです。

名前SFTPユーザーサーバ側パスKopiaから見えるパス容量
TimeMachine-Riokopia-rio/opt/backup/kopia-sftp/TimeMachine-Rio/repository/repository3.0TiB

名前にTimeMachineと入っていますが、実体はKopia用のSFTPリポジトリです。

サーバ側では、ユーザーを通常ログイン不可にしています。/sbin/nologin を指定し、OpenSSHの internal-sftp だけを許可します。また、chrootを使って、それぞれのユーザーからは /repository だけが見えるようにしました。

このあたりは手作業ではなく、Ansibleで管理します。

cd ansible-playbooks/baremetal/kopia-sftp
ansible-playbook -i inventory/hosts.yml site.yml

このplaybookで行うことは、だいたい次の通りです。

  • /opt/backup をXFS project quota付きでマウント
  • kopia-rio ユーザーを作成
  • SFTP専用のsshd設定を追加
  • chroot用ディレクトリを作成
  • Kopiaリポジトリ用ディレクトリを作成
  • SELinuxラベルを設定
  • XFS project quotaで3.0TiBの上限を設定

SSH公開鍵は、既存の rio ユーザーの authorized_keys を再利用しました。これで、普段サーバにSSHログインしている秘密鍵をそのままKopiaUIにも指定できます。

クライアント側を設定する

Mac側にはKopiaUIを入れます。

brew install kopia kopiaui

今回の接続先は kopia-rio なので、KopiaUIのRepository設定は次のようになります。

項目
Host192.168.1.4
Userkopia-rio
Port22
Path/repository
Password空欄
Path to key file/Users/rifujita/.ssh/id_ed25519
Path to known_hosts File`/Users/rifujita/.ssh/known_hosts

サーバ側ではchrootしているため、Kopiaから見えるパスは /opt/backup/... ではありません。必ず /repository を指定します。

スナップショットを作る

Repositoryに接続できたら、KopiaUIで New Snapshot を作成します。

最初は小さめのディレクトリで試すのが安全です。今回は /Users/rifujita/Movies を対象にしてみました。

実行後、Kopia CLIで確認すると、

CFG="$HOME/Library/Application Support/kopia/repository.config"
kopia --config-file "$CFG" snapshot list --all

次のようにスナップショットが作成されていました。

rifujita@macstudio2025:/Users/rifujita/Movies
  2026-07-05 07:20:23 JST ... 267.5 MB files:56 dirs:6

サーバ側でも、リポジトリの使用量が増えていることを確認できます。

sudo du -sh /opt/backup/kopia-sftp/TimeMachine-Rio/repository
sudo xfs_quota -x -c "report -h -p" /opt/backup

実データはKopiaのリポジトリ内に、暗号化・圧縮・重複排除されたchunkとして保存されます。そのため、元データのサイズとサーバ側の使用量は完全には一致しません。

Snapshotとは何か

KopiaのSnapshotは、バックアップデータそのものというより、「ある時点のファイル構成を指す目録」です。

実データはRepository内のchunkとして保存されます。Snapshotは、その時点のディレクトリやファイルが、どのchunkから構成されていたかを記録しています。

このため、Snapshotを削除しても、サーバ側のデータがすぐに消えるとは限りません。他のSnapshotから参照されているchunkは残りますし、どこからも参照されなくなったchunkも、maintenanceで回収されるまでは残ります。

容量を回収したい場合はCLIでmaintenanceを実行します。

CFG="$HOME/Library/Application Support/kopia/repository.config"

kopia --config-file "$CFG" maintenance info
kopia --config-file "$CFG" maintenance run --full

すぐに未参照データを消したい場合は、次のような実行もできます。

kopia --config-file "$CFG" maintenance run --full --safety=none

ただし、これは削除ミスから戻せなくなるので注意が必要です。

まとめ

TimeMachineが使えない環境でも、Kopiaを使えばバックアップを構成できます。

今回の構成では、サーバ側はSFTPだけを公開し、Kopia用ユーザーはchrootされた /repository だけにアクセスできるようにしました。SMBもBonjourも不要です。容量制限はXFS project quotaで行い、3.0TiBを割り当てました。

KopiaはTimeMachineほどmacOSに統合されているわけではありませんが、重複排除、暗号化、世代管理があり、GUIも使えます。IntuneでTimeMachineが禁止されている環境では、かなり現実的な代替案だと思います。

あとは、定期実行のポリシーを決め、たまにmaintenanceを実行し、そして何より復元テストを忘れないことです。バックアップは、取れているつもりではなく、戻せて初めて意味があります。