- Time Capsuleの販売終了後も、小型で低消費電力の機器にLinuxを入れれば、macOS向けの常時バックアップ装置を安価に自作できる
- 送料込み25ドルのHP t520は、デュアルコアAMD G-Series、4GB RAM、16GB M.2 SATA SSD、1Gbps Ethernet、USB 3.0ポートを備え、単一用途サーバーとして十分な性能がある
- ストレージは内蔵M.2 SATA SSDと外付けUSB3ドライブから選べ、2TB 2280 M.2 SATA SSDを使えば総費用は94ドル程度に収まる
- Bodhi Linuxに
netatalkとavahi-daemonをインストールしてAFPベースのTime Machine共有を構成するが、公開後にAFP deprecatedのためSambaを使う案内が追記された
- 初回の460GBバックアップは2Mbit/sでは21日かかる計算だったが、Power Nap、
debug.lowpri_throttle_enabled=0、Wi-Fi APの近くへの配置で120Mbit/sまで改善し、8時間に短縮された
Time Capsule代替としてのThinMachine構想
- Apple Time Machineは2007年にMacへ移行するきっかけとなり、その後はTime Capsuleで無線バックアップを使っていた
- 既存のTime Capsuleは10年以上動作したのち故障し、macOSはバックアップが古いという通知を繰り返し表示するようになった
- AppleがTime Capsuleを終了した後も、Linuxサーバーを設定すれば似たバックアップ装置を自作できる
- 常時稼働の単一用途機器なら、小型で低消費電力、かつインターネットクローゼットに収まるハードウェアが適している
- Raspberry Piも候補だったが、当時は入手が難しく、80ドル超に加えてケースや電源も別売りで、コスト面の魅力が低かった
- 代替として中古のシンクライアントPCを選び、eBayで送料込み25ドルのHP t520を購入した
HP t520のハードウェアと消費電力
- 25ドルのHP t520の基本構成は、シンプルなバックアップサーバー用途には十分
- AMD G-Series GX-212JC デュアルコア 1.2GHz CPUとRadeon R2E
- 4GB DDR3-1600
- 16GB M.2 SATA SSD
- 1Gbps Ethernet
- USB 3.0×2、USB 2.0×4
- DisplayPort×2、VGA×1
- 縦置きスタンド
- 18.5V電源アダプターとケーブル
- Wi-Fiはないが、ルーター横のインターネットクローゼットに置く予定だったため問題ではなく、必要なら空きmini PCIeスロットを使える
- Wi-Fi追加は自分では試していないため、100%動作するかは未確認
- t520はアイドル時6W、それ以外では10Wを消費する
- 平均電気料金を1kWhあたり0.35ドルとすると、6W常時稼働のコストは年間約19ドル
- HP t610のような他のシンクライアントは古いチップセットのため、アイドル時消費電力が10W超になる場合がある
- Raspberry Pi 4は約4Wと計測された
- 標準OSはHP Thin Proで、Tiny Core Linuxベースのカスタムディストリビューション
- HP Thin ProにはCitrixとVMWareクライアントが含まれる
- 元のTiny Core Linuxも試したが、提供パッケージ数があまりに限られていた
バックアップ用ストレージの選択: 内蔵SSDと外付けUSB3
- t520の公式な内蔵SSD対応容量は64GBだが、これはより大容量のM.2 SSDがなかった時代の仕様
- 内部M.2スロットは2242と2260フォームファクタをサポートし、2280 SSDはデフォルトではスピーカーと干渉する
- スピーカーはメインボードを持ち上げた後、ネジ2本を外して取り外せる
- 2280 SSD装着前に、SSD裏面の露出した銅パッドと配線をテープで覆う必要がある
- 固定ネジがないためSSDがソケットから抜ける可能性はあるが、実際の構成では大きな懸念とは見なしていない
- t520の内部スロットはM.2 SATA SSDのみをサポートする
- 大容量SSDはNVMeが多いが、このスロットはPCIe/NVMe用ではない
- HPが不適切なコネクタを選んだため、NVMe SSDが物理的には挿さってしまう
- NVMe SSDを挿すと、SSD、マザーボード、またはその両方を損傷する可能性がある
- 内蔵ストレージを選ぶ際は価格とフォームファクタの差が大きかった
- 2TB 2260 M.2 SATA SSDはAmazonで149ドルだった
- 2TB 2280 M.2 SATA SSDは69ドルからあった
- 4TB 2280 SATA SSDは260ドルで価格が跳ね上がった
- 選んだ2TB 2280 M.2 SATA SSDは正常動作し、2TB ThinMachineの総費用は94ドルになった
- 外付けUSB3ドライブは設置難度を下げる代替案
- 4TB 2.5インチSSDは150ドルからで、より大容量も可能
- ドライブを外して保管したり、他のPCに接続したりしやすい
- t520を開ける必要がない
- 欠点はUSB3エンクロージャーが必要で、見た目がすっきりしないこと
Bodhi Linuxのインストールとパーティション構成
- Ubuntuベースでインストールイメージが小さいディストリビューションを探し、Bodhi Linuxを選択した
- HWE版は標準版より5MB大きい837MBで、より新しいハードウェアをサポートしていた
- Ubuntu ISOのダウンロードは遅かったが、Bodhi Linux ISOはすぐにダウンロードできた
- インストール手順は一般的なUSBブート方式
- 1GB以上のUSBメモリを用意
- Balena EtcherでISOイメージをUSBに書き込む
- t520にUSBを挿して起動
- インストーラーに従ってt520 SSDへBodhi Linuxをインストール
- 内蔵SSDのパーティションはOSとバックアップデータを分離する
/dev/sda1: efi、1GB、ブートパーティションで最初のパーティションである必要がある/dev/sda2: ext4、16GB、Bodhi Linuxインストール用/dev/sda3: ext4、残りすべて、バックアップデータ用パーティション
- マウント位置も明確に分ける
/dev/sda2はルートディレクトリ/にマウント/dev/sda3は/mnt/timemachineにマウント
- インストール後のBodhi LinuxはSSDを5GB強しか使用しないため、16GB割り当てれば追加ツールを入れる余裕がある
Time Machineサーバー用アカウントとAFP設定
sudo apt update && sudo apt dist-upgrade
- Time Machine動作に必要なパッケージをインストールする
sudo apt install procinfo netatalk avahi-daemon
- AvahiはApple Bonjourと同等のゼロコンフィグネットワーキング機能のオープンソース実装で、Macがネットワーク上のthinmachineサーバーを見つけられるようにする
- NetatalkはApple Filing Protocolのオープンソース実装で、Apple Time Machine対応を含む
- 専用の
timemachineアカウントを作成する
- このアカウントには
rootやsudo権限を与えず、/homeディレクトリも作成しない
- Macからサーバーに接続する際、このユーザー名とパスワードを使う
- このパスワードはバックアップデータ暗号化用のパスワードではない
sudo useradd --no-create-home timemachine
sudo passwd timemachine
sudo chown timemachine:timemachine /mnt/timemachine/
/etc/netatalk/afp.confを編集してTime Machine共有を設定する
vol size limitでTime Machineバックアップが使うディスク容量をMB単位で制限できる- ここではドライブ全体をTime Machineに使うため、容量制限は指定しない
hostnameはUnixホスト名と同一である必要はないが、Bonjourネットワーク上で表示される名前として使われる
;
; Netatalk 3.x configuration file
;
[Global]
hostname = thinmachine
[ThinMachine]
path = /mnt/timemachine
time machine = yes
valid users = timemachine
;vol size limit = 500000
sudo systemctl enable avahi-daemon
sudo systemctl start avahi-daemon
sudo systemctl enable netatalk
sudo systemctl start netatalk
- ファイアウォールで必要なポートを開け、Netatalkを再起動する
sudo ufw allow 548
sudo ufw allow 427
sudo ufw allow 4700
sudo systemctl restart netatalk
- この構成はAFPベースであり、公開後にAFPがdeprecatedとなったため、Sambaを使うべきという案内が追記された
電源復旧とMac接続
- バックアップアプライアンスは停電後に電源が復旧したら自動的に起動する必要があるため、BIOS設定を変更する
- 起動直後にF10を押してBIOS設定に入る
Advanced → Power-On Optionsへ移動After Power LossをOnに設定
- MacのTime Machine設定で
Select Diskを押すと、ThinMachineが選択肢に表示される
- バックアップデータの暗号化はMac側で行われ、シンクライアントは暗号化や復号に関与しない
- バックアップ用パスワードを失うと、データを復旧する方法はない
- 初回バックアップには時間がかかることがある
初回バックアップ速度の改善
- MacBookには460GBのデータがあり、Time Machineバックアップはアトミックなので、完了しなければ最初からやり直しになる
- 初回バックアップ速度は約2Mbit/sで、全体完了まで約21日かかる計算だった
- その間にサーバーの電源を入れ直したり、ノートPCがWi-Fi圏外に出たりすると、バックアップを最初からやり直す必要がある
- Power Napをバッテリー駆動時にも有効化した
- Power Napを有効にすると、ノートPCを閉じたりバッテリー駆動にしたりしてもTime Machineバックアップが継続する
- Power Napを無効にすると、バックアップは中断され、再開となる
- 最初のフルバックアップ中はバックグラウンドプロセス制限を無効にした
sudo sysctl debug.lowpri_throttle_enabled=0
- この設定により、バックアップ速度は2Mbit/sから20Mbit/sに向上した
- 初回バックアップ後は制限を再度有効にする必要がある
sudo sysctl debug.lowpri_throttle_enabled=1
- ノートPCをEero Wi-Fiメッシュネットワークのアクセスポイント近くへ移動すると、速度は20Mbit/sから120Mbit/sまで向上した
- 優先度変更とAP近接配置により、460GBバックアップ時間は21日から8時間へ短縮された
使用結果と追加の可能性
- 数日使った後、MacBookの古いバックアップ警告は消え、バックアップはバックグラウンドで正常に動作した
- t520に追加ドライブを接続してNASへ拡張することも可能だが、必要性は感じなかった
- 内蔵ドライブ故障に備えて、外付けドライブに定期的なフルコピーを作る方法もある
- すでにBackblazeをオフサイトバックアップサービスとして使っており、十分な冗長性があると判断した
1件のコメント
Hacker Newsの意見
もうTime Machineは信用していません。数年前、
brewなどを使ってシステム設定全体をほぼ自動化するシェルスクリプトを作り、ときどきシステムを完全に初期化して、そのスクリプトで復旧しています。データのバックアップにはresticを使っています。macOSのマシンがなくてもバックアップを読めるのが大きな利点です。唯一のmacOSマシンにハードウェア問題が起きたとき、Time Machineのバックアップは新しいMacを手に入れるまで事実上使い物になりませんでした。
誰にでも合う方法ではありませんが、Time Machineにはバックアップを5回以上壊されましたし、resticに比べて遅すぎるので、新しいmacOSリリースが出ても再試行する気にはなれません。
9年目も快適に使っている一ユーザーにすぎず、関係者ではありません。
[1] https://www.arqbackup.com
今はCarbon Copy Cloner、Syncthing、Arqを使っています。そのおかげで家族のバックアップはより速く、自然で、はるかに管理しやすくなりました。
ところがmacOSにユーザーアカウントが2つ、つまり自分と配偶者のアカウントがあるのですが、Resticに別アカウントのデータへアクセスさせることができませんでした。管理者で、rootとして実行し、「フルディスクアクセス」も付与しましたが、それでも駄目でした。コツがあれば知りたいです。
brewとbrew caskを使っても手動インストールが必要なGUIアプリは多く、それぞれの設定は複数の場所に散らばっています。自分で入れたCLIやバックグラウンドツール、システム設定まで考えると、Time Machine式のバックアップ、実質的にはディスクイメージなしで、これらすべての復旧を合理的に自動化する方法がよく分かりません。APFS版でも同じ破損を経験したのかも気になります。
Raspberry PiでPi-holeとTime Machineを動かしていますが、これまで買った技術系製品の中で最もコスパの良いものかもしれません。https://saschaeggi.medium.com/use-a-raspberry-pi-4-for-time-...に従いました。
より高価で、別途ケースと電源が必要で、追加のUSB3ケースなしではM.2 SSDを使えません。フラッシュカード破損の履歴もあり、アイドル時消費電力も少し低い程度にとどまります。
大学へ行く娘に使うよう渡しましたが、実際に使ったかどうかはかなり疑わしく、この記事を見るまで尋ねようとも思いませんでした。
メンタルヘルスを守りたいなら、Time Machineの使用をやめて Carbon Copy Cloner [0] を使うことを勧める。ちゃんと動作し、動き続け、考えられるバックアップ・復旧シナリオに関するドキュメントが優れていて、何をしているのかを透明に見せてくれる
Time Machineはうまく動いていたのに、ある時点から動かなくなる。バックアップが壊れていることも、復旧を試みるまで教えてくれない。エラーは難解で、サポートはなく、フォーラムも役に立たず、壊れたバックアップは修復できない。Time Machineは、自分が何をしているのか、していないのか、しようとしているのかについて何の情報も与えない「ユーザーなんて知ったことか」式のアプローチを取っている
データにバックアップする価値があるなら、Time Machineは使うべきではない
[0] https://bombich.com
iCloudでも、どこで聞いても返ってくる答えは「データを同期中です」「一度オフにしてオンにしてください」「再起動してください」だけ。小さな同期問題でもiOSをリセットしろ、macOSを丸ごと再インストールしろと自信満々に言うApple Supportを見ていると、カフカ的なサディズム・ボットと会話している気分になる
これがAppleのプレイブックだ。ソーシャルメディアで公に批判しても無駄で、メールには返事がなく、顧客からの要望は詰まる。ときどき、自分はApple製品を使うために金をもらっているのではないかと思うほどだ
以前のマネージャーが、個人用であれ仕事用であれMacを受け取ったらまずLinuxをインストールすると言ったとき、新人たちは彼を変なGNU/FOSS狂信者くらいに見ていた。彼は笑って、時間が経てば分かると言っていたが、今ではAppleエコシステムがどれほど無力で敵対的か分かる。壁にぶつかり、腹立たしい制限に耐えているうちに、これが唯一のやり方であるかのように感じる人質状態になる
この時点で、Time Machineやデータの完全性と信頼性がかかったAppleの機能を「ちゃんと動く」とか「十分に悪くない」と言ったり、iCloudのようなものにデータのバックアップと完全性を依存したりするのは、ほとんど自己破壊だと思う
iOSで明示的な権限の下でのファイルアクセスがもっと簡単になる日、あるいはAndroidがもう少しマシになる日を待っている。結局、この輝かしい二者独占にプラットフォームを強制的に開かせるしかなく、自分たちからはやらないだろう
Time Machineは無料で、ほとんどの人にとってローカルまたはローカルネットワークのバックアップとしては「十分に悪くない」。リモートバックアップならBorgBase、borgのGUIアプリであるVortaはひどいが、それからBackblazeがまあ何とか許容できる選択肢だ
またCCCには、Borgのような作成後にクライアント側で不変になる書き込み専用バックアップはないようだし、機能一覧にも暗号化や重複排除は見当たらない。 https://bombich.com/features
今はTime MachineでTrueNASサーバーとローカルディスクの両方にバックアップしている。ただしローカルディスクは、挿すのを覚えているときだけだ。ホームディレクトリはArqでB2にバックアップしている
家族にはBackblazeを使わせている。本当に設定したら忘れていられる唯一の方法だった。家族はローカルのTime Machineドライブをいつも挿し忘れるし、ネットワークドライブでTime Machineを設定すると数か月ごとにおかしくなって、バックアップできないというTime Machineのメッセージをそのまま無視してしまう
Backblaze はほぼただ動くし、週に1回メールレポートも送ってくれる。完全復旧は少し苦痛だろうが、バックアップがまったくないよりはマシだ
これを直すための比較的単純なシェルスクリプトを作った
https://github.com/torstenvl/tmutils
まだかなりベータ版なので、使うなら注意が必要だ。主要なメタデータ変更には確認手順があり、
dirdedupeスクリプトはデフォルトでテストモードで実行される。実際に何かを行うには--executeフラグを使う必要があるCCCは素晴らしいが、ほぼリアルタイムではバックアップしないし、バージョン管理もしない。先週金曜に移動中、SDスロットの「内蔵」Time Machineが救ってくれたようには、自分を救えなかったはずだ
筆者は25ドルで16GBのストレージを手に入れ、さらに70ドルを足して2TBに増やしたという点が目を引く。
GNU/Linuxユーザーには、もちろんMicrosoftやAppleのクライアントでも問題なく動くだろうが、ローカルとリモートのミニサーバーにはSyncthingを置き、サーバー側だけでBorgBackupを回す組み合わせが良い。
Syncthingはほぼ即時の同期を提供し、BorgBackupは望む周期と保持ポリシーに合わせた定期アーカイブを提供する。
隔離のために家族メンバーごとに小さなVMを1つずつ用意し、本当に大切なものは管理対象の
~/work/や~/private/に入れるよう伝えた。興味深いことに、APUはAES-NIをサポートしており、SHA用の小さな暗号アクセラレータもある。Raspberry PiがArmv8 Cryptography Extensionsに1ドル余分に使わなかったのとは対照的だ。
同じアイドル時消費電力6.5Wでコア数が倍なので、t520よりt620を勧める。
2コアで十分ならFujitsu Futro s520も良い。
https://heap.ovh/tag/thin-client.html
AFPをNetatalk経由で使うのが本当に正しいのかは確信がない。現在の「ネイティブ」なTime Machineは、ネットワーク上ではCIFS/Sambaをより好むと理解している。
「SMBとAFPのどちらかを選べる場合は、外部バックアップディスクにはSMBを使ってください」
https://support.apple.com/guide/mac-help/types-of-disks-you-...
「心配しないでください。自動の外部バックアップにはBackBlazeも使っていて、すべてのプロジェクトはGitHubと複数のPCにも保存しています」というやり方は賢い。
20年の間に致命的なドライブ故障を7回経験し、そのうち4回は自作バックアップを使っていたときだった。怠けて雑にやったせいで、そのうち2回は多くのデータを失った。自作のバックアップソリューションは自分には合わない。
今日書かれた記事のように見えるが、記事に出てくるMacが5年前のmacOSを動かしている点が重要だ。似た構成でRaspberry Piをしばらく運用した立場から言うと、今では良い考えではないと思う。
最近Time Machineを使うなら、スナップショットのあるAPFSボリュームにバックアップすべきだ。HFS+ディスクよりはるかに速く、信頼性も高い。macOSがいつか新しいHFS+バックアップのサポートを完全に打ち切るかもしれないので、もう勧めない。
問題は、Linux向けのAPFSドライバが、実質的に信頼してバックアップを任せられるレベルでは存在しないことだ。だから現実的な選択肢は、それを処理するMacを用意することになる。私のネットワークでは、Touch Bar以前の最後の世代の1つである古いMacBook Proをバックボーンに有線接続している。高価だが、これが望ましい構成だと考えてよい。
ちなみにネットワーク共有にTime Machineを使うなら、定期的に更新する「最悪の場合」用のバックアップをもう1つ用意することを勧める。ネットワークディスクは便利なので定期バックアップや素早いアクセスには良いが、時々Time Machineが自分では修復できない形で自分自身を壊すことがある。
もう1つの安価なネットワークTime Machineの解決策は、中古のIntel Mac Miniを使うことだ。2.5GHz Intel i5、8GB RAM、256GB SSDの構成が約120ドルほどで、Time Machineディスクをネットワークに公開するよう設定すればよい。
「本物の」Time Machineであるだけでなく、以前に直接接続して使っていた既存のTime Machineディスクに続けてバックアップすることもできる。新たに覚えることもない。
私のメインのTime Machineバックアップ、私と妻のMBP用は、NASのZFS RAIDZ2へSMBでバックアップする方式だ。約2年間かなりうまく動いている。
経験した問題は、設定したクォータで容量不足になることと関係しているようだった。ZFSスナップショットのせいで、Time Machineの自動クリーンアップ機構が期待どおりに空き容量を作れなかったためだ。幸い、ZFSロールバックで最近の正常なスナップショットを見つけ、古いZFSスナップショットを手動で削除して容量を作り、Time Machineの検証を実行したうえで使い続けることができた。その前に手動で「正常確認」スナップショットも作っておいた。
最近ZFS refquota設定を見つけ、上記の面倒な手順を解決し、Time Machineが期待する形でクォータが動作するようにしてくれるようだ。もちろんZFSスナップショットのため追加の容量は使うが、Time Machineのデータはアレイ全体のストレージ容量のごく一部なので問題ない。
もう1つの問題はArchでZFSを使う際のカーネルアップグレードとdkmsの問題だったが、最近NixOSへ移行してからは安定している。Tailscale経由のTime Machineバックアップもかなり良い。
別途、AirPort Extremeに接続したUSBドライブにも2つ目のTime Machineバックアップを置いている。
同じNASでクロスプラットフォームバックアップ用にresticも使い、そのNASがTime MachineとresticのデータのZFSスナップショットをリモートサーバーへ送っている。
最後に金庫の中にUSBドライブを1つ置き、1か月ごとくらいに取り出してローカル接続のTime Machineバックアップを手動で回している。
すべてをバックアップしておくことは、冗談半分本気半分で結婚の誓いの一部だった。失うものが大きい。
リンクを開いた主な理由は、筆者がどのシンクライアントモデルを選んだのか見たかったからで、ちょうど私が1台持っている HP T520 だった
Time Machine については何とも言えないが、ハードウェアと Linux の組み合わせとしては、同様の Raspberry Pi や Odroid のシングルボードコンピューターよりも安定したサーバーだった。消費電力も大きく増えるわけではなく、サイズだけが大きかった