wallet.dat の自動バックアップ
他の多くの方と同様に、wallet.dat のバックアップが必要である。そしてこれはサーバー上にあるため、無人で実行される必要がある。また、このサーバーは宝くじに使用されているため、bitcoind を停止してはならない。
今のところ単にファイルをコピーしており、破損したファイルに耐えられるよう頻繁に行っている。しかしこれは理想的ではない。すべてのトランザクション後にバックアップすべきである（送信時のみ正しいか？ 送金の受信時には新しいアドレスは作成されないはずだが）。あるいは新しいアドレスを作成するたびにバックアップすべきである。
そのため、ファイルをコピーする代わりに、db_dump を使用して内容をダンプし、念のため-r フラグを使用することを考えた。これは機能するだろうか？
理想的な解決策は、以下のいずれかを行う RPC 呼び出しである：
- フラッシュして、新しい RPC 呼び出し（どの呼び出しでもよく、ロック解除コマンドである必要はない）が来るまで更新をロックする
- フラッシュして wallet.dat を別のファイルにコピーする
- フラッシュして jsonrpc 経由でダンプする。各鍵が配列内で個別に返されれば、‘lastseen=X’を指定して新しい鍵のみを取得できる
これは実現可能だろうか？ どれが最も適しているだろうか？
topic 873 がやや関連している。
別のトピックに投稿し始めたが、ここでも繰り返す。このスレッドの方がトピックに特化しているようだ。
主なバックアップの改善は、事前生成された鍵のプールと、ロード時にブロック履歴から見逃したトランザクションをスクレイピングする再スキャンだ。そうすればバックアップは長期間有効に持続する。
nelisky、あなたと同じアイデアを投稿し始めていた。
ウォレットをロックし、フラッシュし、wallet.dat を指定した場所にコピーしてからアンロックする json-rpc コマンドはどうだろうか？プールされた鍵よりも小さなプロジェクトなので、先に実装できるかもしれない。
ファイルをコピーする最もシンプルでポータブルな方法は何だろうか？Boost に何かあるか？
名前は何がよいだろうか？例えば：
backupwallet
別のトピックに投稿し始めたが、ここでも繰り返す。このスレッドの方がトピックに特化しているようだ。
主なバックアップの改善は、事前生成された鍵のプールと、ロード時にブロック履歴から見逃したトランザクションをスクレイピングする再スキャンだ。そうすればバックアップは長期間有効に持続する。
nelisky、あなたと同じアイデアを投稿し始めていた。
そうだ、あなたの別の投稿を見たし、アドレスのプールというのはとても気に入っているが、それらが全部使われた時に簡単にバックアップする方法はまだ必要だろう？アドレス空間が巨大なのは分かっているが、1日に数千のアドレスを配信するアプリケーションがあるかもしれない。
サトシ・ナカモトの投稿（2010年8月25日 15:57 UTC）ウォレットをロックし、フラッシュし、wallet.dat を指定した場所にコピーしてからアンロックする json-rpc コマンドはどうだろうか？プールされた鍵よりも小さなプロジェクトなので、先に実装できるかもしれない。
ファイルをコピーする最もシンプルでポータブルな方法は何だろうか？Boost に何かあるか？
何と名付けるべきか？こんなのはどうだろう： backupwallet
名前も実装アプローチも全て素晴らしい。
ファイルコピーについては、boost 依存を増やす必要があるだろうか？私としては依存の少ないコアライブラリが欲しい。C++では標準のファイルストリームを使えばいいだろう？http://www.dreamincode.net/code/snippet2306.htm のようなもの（ざっと検索した結果で試していないが、正しそうだ）。
さらに良くするなら、ウォレットに変更があるたびにコピーを行うトリガーを追加するのはどうか？まあ、これが適切に動作するにはファイルロックに依存することになるが、Windows ではうまくいかなかった記憶がある。あっちでコーディングしたのは随分前だが 😊
ファイルをコピーする最もシンプルでポータブルな方法は何だろうか？Boost に何かあるか？
mmap(2) + memcpy(3) か？Boost::Iostreams には既に mapped_file Source がある。
サトシ・ナカモトの投稿（2010年8月25日 15:57 UTC）何と名付けるべきか？こんなのはどうだろう： backupwallet
非常に便利そうだ！
メモリーに読み込んで書き出す方法だと、メモリーが逼迫した状況で失敗する可能性がある。
copyfile(const char* from, const char* to)や copyfile(path from, path to)のような、できれば Boost にあるものを探している。見つけてくれれば、実装にかかる可能性が高くなる。
neliskyの投稿（2010年8月25日 16:21 UTC）ファイルコピーについて、なぜBoostへの依存を増やすのか？コアライブラリは依存関係が少ない方がいい。
JSON や wxWidgets の依存関係を置き換える多数のものに Boost が必要だ。Boost は良い、ポータブルなもので、避けるべきではない。
メモリーに読み込んで書き出す方法だと、メモリーが逼迫した状況で失敗する可能性がある。
copyfile(const char* from, const char* to)やcopyfile(path from, path to)のような、できればBoostにあるものを探している。見つけてくれれば、実装にかかる可能性が高くなる。
neliskyの投稿（2010年8月25日 16:21 UTC）ファイルのコピーについて、なぜBoostへの依存を増やすのか？コアライブラリは依存関係が少ない方がいい。
BoostはJSONのために必要であり、wxWidgetsへの依存を置き換える多くのものに使っている。Boostは良い、ポータブルなものだ。避けるべきではない。
では、私が言及したスニペットのシンプルな標準 fstream の使用の何が問題なのか？シンプルが一番だと思う 😊
しかし boost::filesystem の機能を既に使っているなら、そこから copy_file を使える。他に何かのために既に必要でなければ、少々大げさだと思うだけだ。
メモリーに読み込んで書き出す方法だと、メモリーが逼迫した状況で失敗する可能性がある。
mmap が何をするか誤解していないか？mmap / CreateFileMapping はファイルをヒープメモリーに読み込むのではない：http://en.wikipedia.org/wiki/Mmap
Windows に mmap(2)があるとは思えない。自作のものを作ってテストするよりも、既存のファイルコピー関数を呼び出す方が良い。
neliskyの投稿（2010年8月26日 16:21 UTC）しかし boost::filesystem の機能を既に使っているなら、そこから copy_file を使える。他に何かのために既に必要でなければ、少々大げさだと思うだけだ。
ありがとう。どこかにあるだろうと思っていた。
すでに十数箇所で boost::filesystem を使っている。新たに追加される依存関係ではない。そうでなければ各 OS ごとに#ifdef を用意してあらゆる場所でテストしなければならないような、多くのポータブルなものを提供してくれる。
Windowsにmmap(2)があるとは思えない。自作のものを作ってテストするよりも、既存のファイルコピー関数を呼び出す方が良い。
Windows バージョンの mmap は返信したメッセージで言及した：CreateFileMapping
以前のメッセージで、boost からの使い方を述べた：Boost::Iostreams には既に mapped_file Source がある。
すまない、最近非常に忙しくてメッセージを流し読みしているが、それでも追いつけない。
可能な限り Windows API 呼び出しは避けたい。通常 6〜8個のパラメーターが必要で、正しく動作させるために多くのテストが必要で、簡単なことを行うのに 1 ページ分のコードが必要になる。
通常 iostreams は避けている。よく制限にぶつかるようだ。90年代に C++ストリーム標準をやや台無しにしてしまった。残念なことに、正しく実装すればストリームは非常に強力で便利なものになり得る。rpc.cpp で使っているのは、まだ間違いだったと判明するかもしれない。
結論は、自作のものを作ってテストするよりも、既存のファイルコピー関数を呼び出す方が良いということだ。
いいね。
を設定オプションとして指定でき、bitcoinの送信（/受信？）のたびにその関数を呼び出す、というのはどうだろう？
私は新しいアドレスを作るたび、そして btc を送信するときにバックアップを取っている。受信は安全なはずだ。また、他のものも集めていて、ウォレットのオフサイト scp バックアップもやっている。つまりプログラムロジックにトリガーを組み込んでいる、ということだ。だが自動バックアップがあると素晴らしい。バックアップファイルの変更を監視して、それをトリガーにオフサイトを実行することができるからだ。
ただ、私が本当に素晴らしいと思うのは、何らかのイベントメカニズムだ 😊