バックアップのないmysqlのDBを（意図的に）dropし，後から必要なDBだったと分かって救出しようとした時の記録です．
サーバの構成
データの救出を試みたのは，Webサーバとして起動していたRAID1のUbuntu 10.04 LTS（ext4ファイルシステム）．データの救出が必要だと判明した時点で既に時間が経っていたので，あまり望みはないことはわかっていましたが，やるだけやってみることに．
経過
HDDクローンの作成
まずはUbuntuを停止させました．Webサーバなのでできるだけ早く再開させる必要があったため，ディスクのクローンを作り，そのクローンからデータ救出を試みることにしました．
クローン作成に使ったのはフリーウェアのEaseus Disk Copy https://www.easeus.com/disk-copy/ ．Windows機でEXEファイルをダウンロードし，ブータブルディスクを作成します．クローン用のHDDを接続して，作成したブータブルディスクから起動し，セクターごとのコピーをとります．これでHDDのクローンが完成です．
Windows機でのデータ救出
作成したHDDクローンはファイルシステムがext4なので，そのままではWindows機で読み込めません．そのため，「憩いの場」さんのこちらの記事
https://linux.ikoinoba.net/index.php?UID=1297182890
を参考にExt2Fsdを使って読み込めるようにします．
Ext2Fsdの詳しい使い方はこちら
https://ftlabo.sakura.ne.jp/win/ext2fsd/ext2fsd.html
にありました．（ディスクはRead only modeでマウント）
次に， photorec というオープンソースの復元ソフトを使って，ガリガリとデータを読み出します．photorecの詳しい使い方はGigazineさんに掲載されていました．
https://gigazine.net/news/20070720_photorec/
対象とするファイルをDBと*.MYIに限定して，500GのHDDで約6時間回しっぱなし．ファイル名は復元されず，また，領域の重複もあるようで300Gなんて巨大なファイルもみつかりました．で，目的のデータが入っているファイルを特定するため，すべてのファイル群をLinux機に転送し，grepにかけました．（Windowsでgrep的なことをすると経験上ロクなことがないので）
Linux機でのデータ救出
さらに，Linuxでのデータ救出も試みました．ext4でのデータ復元には，extundeleteというGPLのソフトウェアがあり，またも「憩いの場」さんのところに説明書きとUbuntu用のパッケージまで！（普通にソースコードからビルドも出来ました．最初はKnoppixのライブCDでトライしたのですが，ビルドまでの環境設定が面倒だったので，結局もう一台Ubuntuを作りました）
https://linux.ikoinoba.net/index.php?UID=1295979561
ということで，別のUbuntu機からクローンHDDを読み込もうとしたのですが，exundeleteは，read onlyでマウントしたHDDしか走査しない親切設計で，RAIDのパーティションはUSBで接続しただけではマウントすらできません．
なので，まずマウントポイントを /media/hoge とかに作成し，Ubuntuディスクユーティリティーを使って（fdiskでも良し）対象となるパーティションを確認して，
# sudo mount -r -t ext4 /dev/(clone HDD) /media/hoge
とファイルタイプにext4を指定し，リードオンリーでマウントします．
これでextundeleteで走査できるんですが，特定のファイルタイプを探すには recipe が必要です．インストール時に数種類のrecipeが既に用意されていますが，mysqlのデータベースファイルMYDは含まれていなかったので，既存のrecipeを参考に作成しました．recipeの作り方は man extundelete で確認できます．
で，復元したファイルをひたすらgrepすると．
結局，探していたデータは復元出来なかったのですが・・・ね・・・（涙）