はじめに
Raspberry Piを長く使っていると、昔はよく聞いた「SDカードとの相性」という言葉を思い出すことがあります。
最近のカードは品質も安定しており、特に意識することもなくなっていました。
しかし今回、バックアップのためにRaspberry Pi3で SD Card Copier を使ってコピーしようとしたところ、コピー先のカードが認識されず、久しぶりに“相性問題”に直面しました。そのあたりを記録に残します。何かの参考になれば幸いです。
※この記事は体験談であり詳細な手順解説ではありません。ご了承ください。
経緯
ハードウェア構成
- 使用機種：Raspberry Pi 3
- コピー元カード：Ubuntu動作用のSDカード
- コピー先：新規購入のELECOM製 64GBカード
作業の経緯
- 最初にカードリーダーを2台用意してSD Card Copierで試すもコピー先が認識されず
- 仕方なくSDカードを新規に購入
- 購入したカードは認識した
- でも、カードリーダーを2台にすると1台分しか認識しない（別々には認識する）
(ちなみに今までのカードリーダーは1台壊れたので一台は新規購入品) - カードリーダが同じ機種だったので別の機種にしても2台は認識しない。
要するに いつもやっていることが出来なくなった という状況です。
まずここでイライラします。
※ちなみに新規購入のELECOM製 64GBカードは普通にWindowsで使えます。
念のためですが何の問題もありません。
SDカードの「相性」とは？
今回のような“相性問題”の原因として、いくつかの技術的要素が考えられます。
コントローラICの違い
各メーカーのSDカードには、内部にフラッシュメモリを制御する独自のコントローラチップがあり、書き込み管理や電源制御のタイミングが微妙に異なります。
Raspberry Pi側（特に古いPi 3など）とのタイミングが合わないと、認識や転送で失敗することがあります。
USBリーダーの識別競合
同一メーカー・同一チップのリーダーを2台同時に挿すと、USBデバイスIDが同じで区別できなくなり、片方または両方が認識されないこともあります。
フォーマット（ファイルシステム）の非対応
64GB以上のSDカード（SDXC）は出荷時に exFAT でフォーマットされています。
しかし、Raspberry Pi OS（古いRaspbian）やUbuntu 18系では exFAT ドライバが含まれていないため、unknown filesystem type 'exfat' エラーとなります。
→ 対策としては FAT32（vfat）で再フォーマット が確実です。
どう対処したのか
上記の経緯で書いたことをどうしたかもう少し詳しく書きます。
配達で新しいカードを調達した
SDカードを購入しようとしましたが、夜だったため近所の家電量販店は閉店。仕方なく Uber EatsでKIOXIA製 64GBカードをコンビニ（ローソン）から配達してもらいました。
まさかSDカードをウーバーで頼む日が来るとは思いませんでした。もちろん在庫を確認して自分で行けばいいのですが。あと、近くにあるドンキホーテが24時間営業でSDカードも何種類か売っているようです。
購入したこのカードはPiでも問題なく認識。但し、カードリーダー2台でいつものようにSD Card Copierでコピーしようとしたところ、2台同時には認識出来ない。
このあたりでかなりイライラ度が高くなりました。 いつもやっていたことが何で出来ないんだよということです。
ddコマンドによるコピー
仕方ないので、AIに聞いて、LinuxPCを起動して、ddコマンドで対応しました。
SDカードからのバックアップの例
# 1. SDカードのデバイス名を確認
lsblk
# 例: SDカードが /dev/sdb の場合
# 2. バックアップ実行（イメージファイルを作成）
sudo dd if=/dev/sdb of=~/raspi_backup_20251029.img bs=4M status=progress conv=fsync
sync
SDカードへのバックアップを復元する例
# 1. 新しいSDカードを接続してデバイス名を確認
lsblk
# 例: 新しいカードが /dev/sdc の場合
# 2. 書き戻し実行
sudo umount /dev/sdc*
sudo dd if=~/raspi_backup_20251029.img of=/dev/sdc bs=4M status=progress conv=fsync
sync
⚠️ 注意
dd は非常に強力なコマンドです。
指定を誤ると他のディスクを上書きしてしまう危険があります。
実行前に必ず lsblk でデバイス名を確認してください。
不安な場合はAIアシスタントやシェル履歴管理ツールに確認させるのも有効です。
その後、バックアップファイルからSDカードを復元しようすると、「デバイスに空き領域がありません」というエラーが発生。 原因は、元カードより新カードの実容量がわずかに小さいことでした。
またこれで30分ぐらいが過ぎました。
そこで pishrink を使って .img ファイルを圧縮し、再度書き戻し。
結果、すべてのデータと設定がそのまま復元されました。
pishrinkについては以下を参照してください。
https://github.com/Drewsif/PiShrink
結果と教訓
- バックアップ用とはいえRaspberry Pi3はもう古い
- カードやリーダーの相性は今でも無視できない
- Raspberry Pi 3では同一リーダー2台同時接続は避ける
- KIOXIAカード＋Linux環境＋ddコマンドの組み合わせは安定
- 容量差エラーはpishrinkで解決可能
- ddコマンドは環境確認が必須（不用意な実行は危険）
- 出荷時exFATフォーマットのSDXCカードはPi 3では未対応
AIの役割
今回、複雑なトラブルシューティングを進める中で、コマンド構文やエラーログの意味、対処の順番など、AIのサポートが非常に有効でした。
dd のような強力かつ危険なコマンドを扱うときほど、
「この状況で安全に実行してよいか？」をAIに逐次確認しながら進めることで、
リスクを最小限に抑えながら確実にゴールへ到達できました。
まとめ
長く使っていると忘れがちな「相性」や「ハード構成の限界」を、
久しぶりに思い出させてくれる出来事でした。
もちろんRaspberry Piはこれからももっと活用します。
そして今回改めて実感したのは、AIの判断と補助があるとトラブル復旧の精度が飛躍的に上がるということです。そういう時代ですね。
何かの参考になれば幸いです。ありがとうございます。