業務用バックアップソフトのデータベースバックアップがどうにもうまくいかない…と悩んでいたところ、バックアップ「フォルダ」の指定しかしておらず、バックアップ「ファイル」の指定をしていなかったことに気づいた。
気づいたときにはがっくりしたけど、また忘れそうなのでここに書いておく。
borg-backup解説
世の中に多数のborg-backup解説はあるが，さて力になってくれる解説がどれくらいあるだろうか。生成AIに聞いても，80点の回答をよこしてくれる（それはそれでありがたい）が，逆に，痒いところには決して手が届かないんだよな。
そんなわけで，やや特殊なbog-backupを実行した人間の試行錯誤をここに記す。
１ Windows上のソフトウェアが業務用データを外付HDDにバックアップする環境。
２ この環境で，Windowsの外付HDDから情報をLinux機がプルし，Linux機の外付HDDにバックアップする。Linux機，Linux機外付HDDともWindowsからは見えない（業務用外付HDDに読み取り可能なアカウントが見えるのみ）
３ Linux機は，Windows機の外付HDDをSMBで共有してもらい，マウントして，読み取り可能なアカウントで読みに行く。
まずここで問題が発生するのだが，-t cifsでマウントするWindowsから提供されるSMB領域は，linux側がチェックに使用する「inode」（←linux側ではユニーク)がころころ変わるそうだ。
つまり，linux側は，「これは，ユニークなはずなinodeが前回と変わっているので中身が変わっているかも！」と思うかもしれないが，それは-t cifsでマウントすることに伴う宿命なので受け入れなさい，となる。
そこで，代替案として，WindowsでつかっているFileID（ユニーク）を，linux側のinodeに転用しようという話が出てくる。これを実現するのが，windowsのファイルをlinuxでも使えるようにする”(sudo) mount”のコマンドオプションである。
使い方は，sudo mount -o serverino
ほかに並列で使うオプションがあれば，","でつないで使えばよろしい。
特に，ファイルに記入した接続先windowsのパスワードを認証要素として流し込むcredentials=はとても便利である。
４ ここからは環境依存の話になると思う。私の環境では，ctime変更のみ，という情報変更が妙に多かった。そこで，バックアップをとるコマンドである
borg create に，--noctime を加えることに決定。これは，バックアップ先にctime情報を蓄積させないものだ。
次に，同じくborg createに，ctimeが違っても一致と判断するように，--fs-cache=mtime,sizeを加える。
これで，読み込むときにも，mtimesとsizeの一致をもって同一かどうかを判断し，ctimeは同一性判断の材料にしないはずだ。
うちのchatgptは，ちょっと古かったせいか，--ignore-inodeを勧めてきた。そんなのないってぇの。
５ さて，borg-backup本体の話をしてきたが，これは本来，バックアップの書式を書いて，backup.shに固め，borg-backup.serviceがこのbackup.shをサービスの一環として取り込み，取り込んだborg-backup.serviceが，borg-backup.timerを通じて発火（＝backup.shサービスの実行）するというものだ。
なので君は，よくわからないまま，/etc/systemd/system/borg-backup.serviceと，/etc/systemd/system/borg-backup.timerを作らされることになる。
それでよい。
その辺は，各種サイトが参考になるので参考にしなさい。
バックアップ備忘録
今回，ようやく会社のサーバーのバックアップを実施することができたので，その苦労した部分を書き留めることにする。
１ 構成
元のサーバーは，富士通のPrimergy TX1310 M3，HDDは500GB×2でRAID 1を組んでいる。
バックアップは，手持ちのWD Green 2TB HDDである(2011年もの!一応badblocks -vwで完走したのは確認済み)。パーティションを半分に分け，片方にWindowsImageBackupを収納してある。
復元に用いたのは，Windows Server 2016 評価版(14393.0.161119-1705.RS1_REFLESH_SERVER_EVAL_X64FRE_JA-JP.ISO)をRufusで起動可能にしたUSBメモリである。
また，結論からいうと，TX1310 M3のRAIDドライバ(MegaSR1.inf)も復元に必要となった。
復元先デバイスとしては，手持ちのWD Blue 4TB(こちらも2016年ものである。badblocks -vw -t 0x00で完走したのは確認済み)を利用しようと思ったが，最終的に転がっていたCrucialの2.5インチSSD(1年ほど前に入れ替えた他の従業員のPCのもの。未チェック)に，anexの3.5インチ変換マウンタをつけて使用した。
２ 最初は予定通り
Windows Server Backupを利用し，業務に供しているCドライブのベアメタルバックアップ，Dドライブのバックアップイメージを作成する。
ここらあたりは，なんの問題もない。
３ 最初の過ち
さて，電源をとめて，既存のHDDを抜き，4TBのHDDを入れ，評価版の入ったUSBメモリを挿し，電源を入れる。すんなりOSが立ち上がり，バックアップイメージからの回復が…できない。
ああ，外付けHDDの電源が入ってなかった…よし，認識した。認識したドライブが1TBと2TB？1TBというのは，WindowsImageBackupの入ったドライブか？じゃあ2TBってのは，この4TBドライブ？なんで？Copilotに聞いてみるか。……ああそうなの，2TB制限があるのでそういうふうに認識することもある，と。じゃあいいか。バックアップ実行，と。すんなり行くなあ。よし，昼飯でも食いに行くか。
……と思ったのが甘かった。実はこのとき，とんでもないことをしでかしていたのである。
このとき私が参照していたのは，DISKPARTからのlist diskである。ドライブを認識するはずがないのである。したがって，このとき表示されていた1TBのディスクは，外し忘れていたバックアップ用外付けHDDであり，2TBというのはWD Green 2TBのことであった。
４ おかしい
昼飯を終えて戻ると，復元が終わったので，起動させる…が，起動しない。UEFI-BIOS画面に行ってしまう。何度やっても，外付けHDDやバックアップ用HDDを外して起動させてもそう。
頭をかかえ，RAID関係か，とあたりをつけて，LSIの項目を見る。…見ることができるのは，DVD-ROMドライブだけ。ということは，HDDを認識してない？なんで？バックアップの復元のときは認識してたろうに（←大間違い）
５ 最初の試行錯誤
いろいろやってるうちに，「どうやらWD Blue 4TB HDDがコネクタに挿さっていないようだ」という結論になり，不承不承ながらもさしなおす，と，UEFI-BIOS上でHDDを認識した。おかしい，ではなぜ回復できたんだ（←まだ気づいていない）
その後，RAIDを起動させるには，ヴァーチャルドライブというものをつくり，これをOperateしなければならないことを知り，そうする。
…が，うまくいかない。試行錯誤するが，OSからはヴァーチャルドライブを認識できない。ううむ……そうか，RAIDドライバか！
ああ，よしよし，認識した，これで4TB HDDから起動でき…ない…？（当たり前だ，この4TB HDDには何も入っていないのだから）。
しかし，そのことに気づいていない私は，Copilotに聞きながらInitializeしたり（Copilotは堂々とInitializeしても大丈夫ですよ！データは消えません！」とかぬかしやがった）するが，当然ながらうまくいかない。
６ 転機
頭をかかえた自分は，ふと，2TBの外付けHDDの中身をのぞいてみる気になった。中身がぶっこわれてるんじゃないか，と思ったのである。
除いた私は驚愕した。中身は，普通のCドライブで，WindowsImageBackupはどこにもなかったのである。
そのとき，4TB HDDを「さしなおしたらUEFI-BIOSで認識した」ことを思い出す。…そうか，つながってなかったのか！ということは，あの2TB HDDはWD Green 2TBであり，外付けの1TBには…そうだ，まずWindowsImageBackupをとる練習として作成した，Cドライブだけのベアメタルバックアップが入っていた！
ということは…外付け2TB HDDを起動ドライブにすれば…起動成功！
７ よし，やり直しだ
まあ，イメージが消えてしまったものはしょうがない。WD Green 2TBを，こんどは３分割にして，元のサーバーのWindowsImageBackupをとる…よしよし。
復元先はどうしよう，もう午後４時だし，時間もない。転がってる500GBのSSDにするか。転送も早いだろうしな。…マウンタ買ってくるか…
８ マウンタに取り付けてみたものの
よし，買って来たぞ，3.5インチ HDDと，ねじの位置まで互換だって。2.5インチSSDを内部コネクタに挿し，3.5インチHDDと同じ位置に外部コネクタがあるっていうから，まあ安心だ。マウンタに取り付けて下からねじを…あれ？ねじの位置が合わない？まあ，ぶらぶらしないからいいかな…
※全然よくない。ねじ位置があわなかったのは，2.5インチSSDが内部コネクタに挿さってなかったからである。
さて，とりつけて…やっぱり認識しない。おかしい。おかしい。……外側の3.5インチサイズのケースを取り付けるとき，中が動いちゃうのかな，ねじでしっかり止められてないから…よし，上蓋を外して，2.5インチHDDを抑えながら差し込んでみよう…って，なんか動いた！？どこか折ったか！？取り出して，表裏を確認して…あれ，ねじの位置があってる。ということは，いまのが正しい差し込み位置か！だから認識しなかったのか。ねじしめて，とりつけて…よしよし。認識してる。ヴァーチャルドライブをつくって，Operateして…よし，起動！
９ その後
長かった。MegaSR1.infを読ませることはできたが，そこから先がながかった。いくらやっても，回復先がみつからないエラーで終了してしまう。
対策として，いろいろやった。GPTにコンバートしたり，フォーマットしたり，パーティションつくったり，ドライブレターを変えてみたり。
で，最終的にうまくいったのが，
(1) USBメモリだけで起動
(2) コマンドプロンプトでドライバを読み込ませる
(3) コマンドプロンプト終了
(4) 外付けHDD接続
(5) 再びコマンドプロンプトで外付けHDDが見えるのを確認
(6) イメージから回復
の手順であった。最初から全部つないではいけないようだ。
１０ おわりに
かくして，午前９時から午後１０時まで及んだ戦いは終わった。復元したSSDで，業務用アプリを動かすことができることを確認し，電源を落とし，もとのHDDを戻し，再びサーバーに電源を投入。午後１０時３０分帰宅。
祝杯だー，ということでゼロコーラ500mlとセブンイレブンのやっすいグレープフルーツサワー500mlを1:1で割って飲む。美味かった。
ガチャの試行回数（平均）の計算
やってみたら面倒くさかった（copilotにやらせようとしたら、さぼって不正確な答えを返してきやがった）ので、備忘として書いておく。あと、書いてたらいつのまにかお気持ち表明になってしまってた。
天井のないガチャの場合、排出率pに対し、平均試行回数は1/pになるので話は簡単。問題は、天井のあるガチャの場合、どのくらいを平均試行回数と想定して、資源を備蓄しておけばよいか、である。
例として、排出率0.7%(0.007)、200連で天井のガチャを想定する。プリコネである。
1.1回目で排出されるケース
確率は0.7%(p)で、試行回数は1回である。確率×試行回数は、0.007である。
2.2回目で排出されるケース
確率は、1回目外れ・2回目当たりであるから、(1-p)×p、試行回数は2回である。確率×試行回数は、0.013902である。
3.3回目で排出されるケース
確率は、1・2回目外れ、3回目当たりであるから、(1-p)^2×p、試行回数は3回である。確率×試行回数は省略。
4.n回目で排出されるケース（ただしn<200の自然数）
つまり、(1-p)^(n-1)×p、試行回数はn回である。確率×試行回数は省略。
5.200回目で排出されるケース（＝天井）
確率は、(1-p)^199×1（約24.71%）、試行回数は200回である。確率×試行回数は約49.42である。
6.全てを足し合わせる
1回目で排出されるケースの確率+2回目で排出されるケースの確率+･･･200回目で排出されるケースの確率=1となる。Excelで確かめた。
1回目～200回目までのそれぞれの、「確率×試行回数」の合計は、約107.80である。
ちなみに、1回目～199回目までの「確率×試行回数」の合計は、約58.38である。
7.つまり
平均で言えば、排出までの試行回数は107.80回になるので、十分に大きな数N回のガチャを回す場合に必要なジュエルの備蓄量は、N×107.80×150ジュエル、ということになる。年間30キャラクターと考えると、485,100ジュエルである。ただし、M回(M<N)のガチャを回し、N-Mが小さくなった場合において、ランダム性により平均より多くガチャを回さなければならなかったとき、次のガチャを引けないということが起こりうる。特に、2連続天井（発生確率約6%）で、平均試行回数約4回分のジュエルを消費してしまうことは留意すべきであろう。
また、直感には反するが、天井しなかった人の平均試行回数は58.38回となる。天井がない場合の平均試行回数(142.86回)とかけ離れていて直感に反するが、「約24%の200回(以上)引いた人」をカウントから除外して平均をとるので、こうなるということである。
これは、運営から見た数字ということもできる。たとえば１万人が新キャラを入手したとすれば、ガチャは107.80×10,000回繰り返された、と考えてよい。ガチャ1回150ジュエルについて、300円の売上げであると仮定すると、１万人が新キャラを入手する場合の想定売上げは、323,400,000円となる。もちろん実際には、無償ジュエルを使っていたり、ガチャチケットを使っていたり、お得な値段で購入したジュエルを使っていたりする分もあるので、実際の売上げはもっと低くなるはずだ。推測の立てようがないので妄想するしかないが、半分とか、３分の１くらいだったりするのだろうか･･･？
仮に３分の１だったとして、これは逆から見ると、「ガチャで１億円の売上げが上がった場合、そのキャラを引いたユーザー数は、約１万人である」ということになる。ニューイヤーサレンのセルラン売上げどんぶり勘定が8000万G（G=ぐらい。円ではない）ぐらいなので、そのくらいのユーザー数なのかなあ、と思った次第である。
8.なんでこんな金勘定のことを考えたのか
サイゲームスの中におけるプリコネの位置づけは、おそらくPPMでいうところの「金のなる木」なのだろう。自分がプリコネを始めた2周年直後は、アニメ1期もあったし、まさに「花形」だったのだろうし、だからこそアニバーサリーイベントで踊らせる3Dキャラ（1キャラ数百万～かかるらしいのに、アニバーサリーイベントの場面でしか使ってないはずだ）を開発できたり、プリグラみたいなものを開発できた（開発コストを投下できた）りしたのだろう。（サイゲは商売上手なので、そうやって得た知見は別のゲーム、別のかたちで回収することを考えるだろうし、それができるのだろうと思うけれども）
だが、どこかのタイミングで、あるいは徐々に時間をかけて、サイゲは、プリコネを「花形」から「金のなる木」へと位置づけた。つまりコストを掛けても金を回収することができない商品であるとみなした。
そうすると、集金するためにコストを投じるのは割に合わない。頭をひねって（＝コストを投下して）も、それに見合った金を生まないなら、頭脳は別の、もっと成長性があって頭をひねれば金を生む見込みのあるゲームの開発の方に回した方がいい、それは企業として当然の判断だ。だから、プリコネ開発陣に残るのは、（申し訳ない表現になってしまうが）二流の頭脳になってしまう。
二流の頭脳が集金方法を考えるから、どうしても集金が下手になる。つまり、課金することが嬉しくない、課金の義務感がある、みたいなことになる。属性だって、スタミナパックが500ptだから5属性にして深域回るのに500pt使ってね、なんて金稼ぎがストレートすぎやしないか。これが、たとえば4属性400ptだったら、属性のために買っても100ptのお釣りが出るわけで、スタミナパックを「買わされている」感は軽かったのではないか。
もちろん、4属性400ptでいいのかどうかという話はあるだろう。さらには、スタミナパック以外の新たな課金手段を設けて、そこでお得感を感じさせる方法があるのではないかとか、無限に選択肢はあるだろう。そういう無限の選択肢からある一つの集金方法を選んで洗練させるのは、それはそれはコストのかかることだろう。
でも、サイゲは、コストをかけて頭をひねって気分良く課金させる手段を考え出すということを「しない」という選択をした。それだけのコストを、プリコネに投じる価値がないと判断した。そういえば、キャラクターソングのCDシングルのリリースも終了した。それも、プリコネというブランド形成にそれだけのコストをかける価値がない、リターンが十分には見込めない、という判断の表れなのだろう。
プリコネは、サイゲの「金のなる木」として、コストをかけずにリターンを上げることを命じられた（あるいは、そう命じられていたことを、私はようやくにして気づいた）。いわゆる課金圧は高まり、義務感は強くなり、窮屈に感じることになるのだろう。それは避けられない。かくなる上は、きちんとした終わり、打ち切り感のない終末――たとえば神撃のバハムートで実現したような（自分はユーザーではないので正確には「実現したように見える」なのだが）――を迎えることを願う。
SDカードの速度の話（備忘録）
1.規格の種類
SD / SDHC / SDXC ･･･容量の規格。～2GB(FAT16)、~32GB(FAT32)、～2TB(exFAT)。
スピードクラス Class 2 / 4 / 6 / 8 / 10
ビデオスピードクラス V6 / 10 / 30 / 60 / 90
UHSスピードクラス（鍋底=Uマーク） U1 / 3
バスインターフェーススピード UHS-I / II / III
容量規格はまあ良いだろう。
スピードクラス、ビデオスピードクラスは直感的で分かりやすい。
UHSスピードクラスとバスインターフェーススピードは、まあごっちゃになる。
このほかに、接続するPC側がUSB2.0/3.0か、というのがある。
2.スピードクラス、ビデオスピードクラス
書き込み速度の最低保証値を、MB/secで標記したもの。
3.UHSスピードクラス
これも書き込み速度の最低保証値で、U1は10MB/sec、U3は30MB/secである。
ロー側の規格のスピードクラスと、ハイ側の規格のビデオスピードクラスの間に挟まれて存在感が薄い気がする。気がするだけかもしれないが。
4.バスインターフェーススピード
最初に策定された（と思われる）のが、デフォルトスピードモード(12.5MB/sec)とハイスピードモード(25MB/sec)。
その後に策定されたUHS-I規格では、最大読み取り速度104MB/secであったが、もっと速く読みたいという需要があったため、SDカードメーカーが独自規格をつくり、「うちのリーダーと組み合わせたらもっと速く読めますよ」と謳っている。
で、もっと上を、ということでUHS-II(312MB/sec)、UHS-III(624MB/sec)の規格を作った。
今のSDカードの公称速度については、それが「UHS-I + SDカードメーカー規格」による速度なのか、UHS-IIによる速度なのかを区別しないといけない。「UHS-I + SDカードメーカー規格」の公称値の場合、他のメーカーのカードリーダーと組み合わせると、その読み取り速度はUHS-I規格の最大値である104MB/secあたりに落ちることになる。
5.USB2.0/3.0
乱暴に言うと、
USB2.0 だいたい20MB/secが実効速度。時代と合致規格の関係で、おそらくハイスピードモードを採用してるんだろう
USB3.0 UHS-I規格を採用していれば100MB/sec弱。（メーカー独自規格と合致していれば、さらに上）
USB3.2 環境が良ければ、メーカー独自規格と合致していれば、メーカー公称値280MB/sec行くものもある
6.まとめ
USB2.0接続ならハイスピードモードのカードリーダーだろうから、20MB/sec。手元のカードリーダーがその値だし、2011年のデジカメwatchの記事もそうだったんで、そういうことなんだろう。
USB3.0以上とUHS-Iの組み合わせなら、メーカー問わずとりあえず80～100MB/secくらいの読み取りが出ると思って良さそう。実勢書き込み速度は･･･その半分くらい？（憶測）スピードクラスは「最低保証」なので、その値は上回るだろうけれど。
※問題は、カードリーダー側の商品仕様を見てもUHS-Iに対応しているかどうかは書いてなかったりすること。
それ以上の数値を求めるのであれば、カードとリーダーのメーカーを合わせることになるけれど、書き込み速度の方はそんなに上がらないんじゃないかな（憶測）。
確率と期待値の話
突然だが、DMMのポイ活の一つに、「HIGH&LOW」というゲームがある。
自分に配られたトランプのカードの値が、提示カードよりも高いか低いかを予想するゲームで、予想をあてれば、★を１つもらってゲームを辞めるか、もらった★をかけてゲームを続行するかを選択できる。負ければゲーム終了で、それまでどれだけ勝っていても、★は１つも獲得できない。引き分けならば再勝負。そして、★を５つ貯めれば、１ポイントに交換できる。
このゲーム、どのように振る舞ったときに、もっとも効率よく★を獲得できるだろうか。
注：めんどくさいので、小数点第４位を四捨五入する。
第１ １回１回のゲームの勝敗の確率
ゲームプレイヤーがとるべき「HIGH」「LOW」の選択肢は、ほぼ自動的に定まる。数字が6以下であればHIGHを選択すべきだし、8以上であればLOWを選択すべきだ。
(1) 単純勝率（１発で勝つ確率）
勝率は、AorKが提示された場合は12/13、2orQのときは11/13･･･で、6or8のときは7/13。7のときは、HIGHorLOWいずれであっても勝率は6/13である。
これらの出現率はいずれも等しいから、単純勝率は、0.633となる。
(2) 引き分け再勝負の勝率
次に、引き分けについて。どのカードが場合でも1/13の確率で引き分けとなるが、その場合は再勝負となるのだから、結局引き分けの場合の勝率は、勝ち・負けのみを抽出した場合の勝率平均として考えてよいだろう。
そうすると、勝ち負けのみを抽出した場合におけるAorKの勝率は12/12、2orQのときは11/12･･･となり、6or8のときは7/12、7のときは6/12となる。これらの出現率は等しいので、結局のところ、引き分けを引く場合(1/13=0.077)における勝率は、0.7692となり、これは結局のところ、0.059となる。
(3) 最終的な勝率
最終的な勝率は、単純勝率（１発で勝つ確率）＋引き分け再勝負をしたときに勝つ確率、であるから、合計して0.692となる。
第２ 連勝確率
これは単純だ。自乗していけばいいだけだから、
１勝 0.692
２連勝 0.479
３連勝 0.331
４連勝 0.229
５連勝 0.159
である。
第３ ★獲得期待値
こちらも単純で、連勝数＝★獲得数なのだから、「○連勝で止める、としたときの★獲得期待値」は、単純に掛け合わせればよい。したがって、
１勝で止める場合の獲得期待値 0.692
２連勝で止める場合の獲得期待値 0.958
３連勝で止める場合の獲得期待値 0.993
４連勝で止める場合の獲得期待値 0.916
５連勝で止める場合の獲得期待値 0.795
となる。ここからすると、３連勝で止めるのが一番★獲得期待値が高そうだ。
第４ 広告を見るとチャンス２倍
ところがそうは問屋が卸さない。広告を見てからHIGH&LOWに挑戦すると、敗北しても１回に限り再チャレンジができるのだ（勝った場合はできない）。
再チャレンジとなる確率は、連勝しなかった場合の確率であるから、
１勝止めの場合 0.308
２連勝止めの場合 0.521
３連勝止めの場合 0.669
４連勝止めの場合 0.771
５連勝止めの場合 0.841
である。
第５ えーっと･･･
恐ろしいことに、再チャレンジにおいて、最初のチャレンジと異なる○勝止め戦術を採用することは可能である。ということは、全ケースの検討をせねばならんのか･･･
と思ったが、１回のチャンスしかない場合に、最も★獲得期待値の高い戦略は3連勝止め(0.993)であることは既に判明している。ということは、再チャレンジの時点では最適戦略は３連勝止めに決定しているということだ。そして、再チャレンジに進行する確率に、3勝止め期待値を乗じれば、再チャレンジステージにおける★獲得期待値がでることになり、それは、
１勝止めの場合 0.308×0.993=0.306
２連勝止めの場合 0.521×0.993=0.517
３連勝止めの場合 0.669×0.993=0.664
４連勝止めの場合 0.771×0.993=0.766
５連勝止めの場合 0.841×0.993=0.835
となる。
第６ 結論
そうすると、HIGH&LOWにおける核戦略における★獲得期待値は、
(1) １勝止め→敗北時は３連勝止め 0.692+0.306=0.998
(2) ２連勝止め→敗北時は３連勝止め 0.958+0.517=1.475
(3) ３連勝止め→敗北時は３連勝止め 0.993+0.664=1.657
(4) ４連勝止め→敗北時は３連勝止め 0.916+0.766=1.682
(5) ５連勝止め→敗北時は３連勝止め 0.795+0.835=1.63
であるから、「4連勝止め→敗北時は3連勝止め」とするのが最も★獲得期待値が高い、ということになる。
･･････あってんのかな、これ。
