2019年8月12日月曜日

生命保険の契約変更の変遷とその他保険について

 終身保険の払済をしたのは先の通りですが, あまりにもお粗末な保険契約について他の方の参考もしくは反面教師になればとここに記します.

学生の時に, 保険に入るローカルブームがあり, 終身 1000 万円, 一時払い 2億円 (!!!) の保険を入った. 当時月額 22000 円程度のものに入った. 何故入る必要があるか, 幾ら入る必要があるかなど全くなく契約した. 2 年後一時払い 2 億円はどう考えても必要ないので (それでも) 5,000万円の契約に変更した. もちろん独身で実家暮しなので全く必要ない. その後, この一時払いも無くした. 証書もどっかに行ったので詳細は忘れてしまっているが, この状態で暫く支払っていた. 契約から 20 年立ち保険料も 2,000 円ほど上り, 平成 26 年に入院給付金も解約した. そして今年平成 31 年 (令和元年) 終身部分も払済にし, 保険会社に支払う保険料は 0 円になった.

契約内容の変遷
この間, 大事故も病気もせず保険にお世話になる事はなかった. もちろん丈夫な体にしてもらった親に感謝であるが, マネーリテラシーがまったくないおバカな保険屋に都合の良い客になっていた. なまけものに最適なインデックスファンドの定期的買付け投資を始めてから保険と投資もしくは貯蓄をやっと切離して考えられる様になってきて, 頭だけでなく体で行動が起せる様になってきた.
いやー, それにしても細かく減額をしていったなぁと思う, 若い自分が前に行たら, 保険はいらん! こつこつインデックス投資しろと言いたい.


最近は保険に関する指南 (暴露) 本やブログ, youtube など参考にできる情報が多数あり, やっとちゃんと頭の中に入ってきた. なんともボーっと生きてきたと残念な感じである. しかし, 性格や考えはそう簡単に変わらないし, 変えようとも思っていないので, 死ぬまで続くであろうが, それでも今色々変えていけるのはよかったと思う. しかしまだ個人年金保険や地震保険の解約, また火災保険を火災共済への変更が残っているが, ぼちぼちやっていこうかと考えている. もちろん資産もそれほど無ければ多少の月額の保険料を払って家族が路頭に迷わないもしくは軽減できる様にする必要があるが, 現状それは問題ないのではないかと考えている.

現状考えている最低限必要な保険は以下と考えている.

- 火災保険 (地震保険なし)
- 個人賠償責任保険


場合において必要なのは

- 団体信用生命保険 (家を借金で購入した場合)
- 任意自動車保険 (車を所有している場合, 車両保険はなし)
- 掛捨生命保険 (家族が生きていく為の十分な資産を確保できていない場合)


とにかく貯蓄型の生命保険や個人年金保険は必要ない. 貯蓄と発生確率は低いが自分が払い切れない事態の為の保険を組み合せるのは, 目的と手段が正しく認識できていないと言わざるを得ない. 貯蓄したいのであれば, 債権もしくは株式に投資すれば良いし, 保険は掛け捨てでコスト重視の商品を購入すれば良い.

最近, えっ! そうなのと思ったのが地震保険で, この保険は建物の為の保険でなく, 地震による火災で家屋が消失した時に直近の生活が路頭に迷わない様にする為の物だと知った. その為, 火災保険で契約した家屋の保険料の半分が上限となっていて 100% 保証されるわけではない. 要するに地震での火災は保証しないという事だ. もちろんお金に色は着いていないので家屋の為に支出する事ができるが, それにしては保険金が高い.

とにかく, 次のターゲットは, 火災保険 (地震保険) を火災共済に変更する事かな.

生命保険控除を捨てて, 契約していた終身保険を払済みにした.

以前より契約していた終身保険を払い済みにした. 保険内容は死亡時 1000 万円の保険で, 契約当時は特約など色々付けていて徐々にダウンサイジングして最後の最後に終身保険のみのになっていた. 月約 8000 円程度の保険金でお宝保険と言われる部類の保険なので満期まで払うのも良いが, 以下の理由で払済にする事にした. この払済は, これから支払う分を停止して, 今まで支払った金額のみの運用とし, その分死亡時に受け取る保険金を減額するものである. 払済にする事でどれくらい保険金が減額されるかは, 支払った金額と契約時の利率などで計算されるので, 正確に知るには保険会社に確認が必要になる.

今回窓口に行く前にチョー概算で計算して, 自分自身納得いくかどうか考え, 払済にする理由 (大義名分) を挙げてみた

- 保険はインフレに弱い (保険受け取り時の 1000 万円の物の価値が現在より低くなる)
- 長期資金が流動性が低くなる.
- 解約返戻金が支払金額に比例せず指数的 (始めの頃は損をする)
- 死亡しても家族が路頭に迷わないくらいには資産を確保した.
- 死亡保険なので自分で使えるわけでない (余命半年宣言で支払, そんなん使える状態か!).
- 概算 600 万円程度になると算出

特にインフレに弱い事, 流動性がなくなる事が最大のリスクと考えたのが大きい. もちろんそれなりの資産を確保という前提にある.

早速, 窓口に行き払済を伝えると, 払済前の状態の契約明細を出していただき, 払済後の受取保険金額を出してもらった. そこで示されたのは, 約 780 万円という事だった. 約 78% off であるが, 自分的なテキトー概算よりは十分もらえそうなので, 即決で払済にした. 勿論対応していただいた方から, "お宝保険なのでこのまま払い続けた方がいいですよー", また "今回払済にする理由はなんでしょうか" とか一応お決まりの言葉があったが, あまり色々言わなかった. まぁ, インフレがどうとか流動性がどうとか相手は十分わかっている話なので, 単に息するために話をするだけなので, お茶を濁した...

これで月々 8000 円の相対的に手取収入アップとなる. 本来なら, ETF, 投資信託の積立の金額 up なのだが, いまは積立金額ダウンをしており, 早く来い来い大暴落状態で, 現金を増していこうと思う.

まぁどうでも良いが, まだ個人年金保険の契約もあり, 月 1 万円の支払をしている. 手数料として毎月 0.3% の 30 円を払っており, まだ良心的な手数料だとは思うが, これもやはり, インフレリスク, 流動性をなくしており解約したいところだが, 会社の福利厚生の一貫のものを契約しておりちょっと面倒なので, とりあえず退職までは持っておくか...

2019年8月5日月曜日

一般 NISA の米国株式を特定口座に移管した時の株価とドル円レートについて

 先日 一般 NISA 2016,17 年の VTI を特定口座に移管  で書いた通り VTI を特定口座に移管したが, 移管時の USD の株価と USDJPY は, 移管後の口座内にある USD での株価, ならびに JPY の総額から USD の株価ならびに株数を割ったものから求めていたが, 2 回目以降はこれでは不明確になる. その為コールセンターに問合せて, 移管時の USD の株価ならびに USDJPY を知る方法があるかを問合せた.

回答は, 四半期に送られてくる "取引残高報告書" で確認せよとの事だった.
しかし, ここで分るのは

- 取引日
- JPY の株価
- JPY の総額

JPY のみで USD 関連は全くわからない.
そので言われたのは, 取引日から Yahoo finance などから USD の株価の終値を取得, その後 JPY の株価から USD の株価を計算してくださいだった.

直近の取引残高報告書は 9 月に来るはずなのでそれで確認しようと思う.

2019年8月1日木曜日

12TB RAID5 fsck 通らず. 被害 10 filesで復活

またまた, 12T RAID5 がおかしくなり, SAMBA 系由で file が見えなくなった.
Ubuntu 上からも見えなくなった. というのも, この Ubuntu マシンは足元に置いていて, オットマン状態になっていて, ちょっとした拍子で PC を動かしてしまった. その時に eSATA が unlink 状態になったのだろうと想像される.

reboot 後, 普通に fsck が通ると思ったのだが, 全く通らない. とりあえず 1日待っても fsck が通らない. というか fsck 自体が cpu load avarage が 100% のままずーと進まない状態になっていた.

root@xxx:/home/yyy# fsck -y /dev/sdb
fsck from util-linux 2.20.1
e2fsck 1.42.9 (4-Feb-2014)
/dev/sdb contains a file system with errors, check forced.
Pass 1: Checking iノードs, blocks, and sizes

Running additional passes to resolve blocks claimed by more than one iノード...
Pass 1B: Rescanning for multiply-claimed blocks
Multiply-claimed block(s) in iノード 12: 375912184
Multiply-claimed block(s) in iノード 56102605: 120293546
Multiply-claimed block(s) in iノード 256639065: 1029258958
Multiply-claimed block(s) in iノード 586416835: 898879174
Multiply-claimed block(s) in iノード 717885620: 375912184 1029258958 120293546 898879174
Illegal block number passed to ext2fs_test_block_bitmap #3422481702 for multiply claimed block map
Illegal block number passed to ext2fs_test_block_bitmap #4258085766 for multiply claimed block map
Illegal block number passed to ext2fs_test_block_bitmap #2964345158 for multiply claimed block map
Pass 1C: Scanning directories for iノードs with multiply-claimed blocks
Pass 1D: Reconciling multiply-claimed blocks
(There are 5 iノードs containing multiply-claimed blocks.)

File /disk1 (iノード #12, mod time Wed Mar 11 22:20:48 2015)
  has 1 multiply-claimed block(s), shared with 1 file(s):
    file.201907170.img (iノード #717885620, mod time Sat Sep 18 14:15:14 2100)
Clone multiply-claimed blocks? yes



とりあえず file.img がおかしい事がわかったが, fsck が通せないので, とりあえず mount して ls すると以下の通り
超絶おかしな状態になっていた.

-rw-rw-r--     1 ppp        sssss            890  7月  5 07:08 file.20190716a.txt.1~
-?????????     ? ?          ?                  ?             ? file.201907170.dat
drws--x--- 34433  343389890 1888527826     49152  8月 12  1964 file.201907170.img
-?????????     ? ?          ?                  ?             ? file.201907170.tar.gz
-?????????     ? ?          ?                  ?             ? file.201907170.txt
-?????????     ? ?          ?                  ?             ? file.201907170.txt.1~
-?????????     ? ?          ?                  ?             ? file.201907170.txt.2~
-?????????     ? ?          ?                  ?             ? file.20190724a.dat
s--Srwx-wt 40825 4203306669 2869282342         0  3月 31  1979 file.20190724a.img
-?????????     ? ?          ?                  ?             ? file.20190724a.tar.gz
-?????????     ? ?          ?                  ?             ? file.20190724a.txt
-rw-rw-r--     1 ppp        sssss         558035  7月 26 07:07 file.201907260.dat
-rw-rw-r--     1 ppp        sssss         189880  7月 26 07:05 file.201907260.img
-?????????     ? ?          ?                  ?             ? file.201907260.tar.gz
-?????????     ? ?          ?                  ?             ? file.201907260.txt
-rw-rw-r--     1 ppp        sssss           1060  7月 26 07:12 file.201908xx0.txt
-?????????     ? ?          ?                  ?             ? file.txt



permission, uid, gid などが ??? になってしまっている. またそうでなかったとしても regular file が directory file になっていたりする.
とにかく, ほとんど file はなくてもなんとかなりそうだが, file.txt は残しておきたいと思ったのだが, copy しようにも I/O error となる. おかしな状態のものは抹殺しようと rm したがこれまた I/O error となる. ls -il で inode を表示させても ? 状態でとにかく何もできない... file の情報だけあった inode は開放されているのではないかと思う.

そこで, とにかく file 情報を消す方法がないかと調べてみると debugfs でできそうな感じがし, とりあえず debugfs を動作させた.

 debugfs -w /dev/sdb

多少挙動が違うが, 一般的な shell の様 cd, ls が使えた. ただ ls は less 想像のものが動作し, 微妙に使いずらい. また, console の history に残っていないので, どの様に表示されたかなどここに書く為の情報はなくなってしまっている. ただ, やった事はとりあえずすべての ? 状態の file を rm していった.





すべての ? 状態の file を消し, debugfs を抜け再度 fsck してもやはり,

  has 1 multiply-claimed block(s), shared with 1 file(s):
    file.201907170.img (iノード #717885620, mod time Sat Sep 18 14:15:14 2100)
Clone multiply-claimed blocks? yes


file.201907170.img は "drws--x---" の file で, regular file が directory file になってしまっている. しかも suid 状態!!!  とりあえず rmdir で削除や cd で中に入ろうとするができない. もともと regular file なので, それはあたりまえかと思う. とにかく 644 にしようと思うが, 通常の mount した状態からは chmod が不可能だった. やはり debugfs の出番だ.






debugfs では chmod らしきものは "modify_inode" で, inode を持っている file に対して属性を変更できる (今回はなぜか 666 に変更)
すべては表示しないが, Mode のみ変更し, あとは enter をひたすら連打した.

debugfs:  modify_inode file.201907170.img
                          Mode    [044710] 666
                       User ID    [46786]
                      Group ID    [42450]
                          Size    [49152]
                 Creation time    [-251420407]
             Modification time    [-170039582]
                   Access time    [987520066]


debugfs 上で再度 ls をすると, ? 状態はすでになくなっているが, その他の file も正しい uid/gid に変更されすっかり問題がなくなってしまった.

最初から fsck で file.201907170.img がおかしいと出ていたので, ひょっとすると残しておきたかった file.txt も問題はなかったのかもしれない.
しかし, すでに debugfs で rm 済みなので, もう帰ってこない. といっても, emacs の backup file があったので, そこから直近のものだけを書き加えてそれっぽく復旧しておいた.

fsckでいくらたっても終らない状態になった時は,
fsck で erorr になっている対象のみ, mount -o ro で確認や debugfs で確認し, 変更もしくは削除の対応をした方が良い. それを何度か繰替えせば, どの file も消さずに復旧できたかもしれない. とはいえ eSATA で HDD を外部接続しているのでそれが問題と思うので, HDD を 2つ購入し PC に内蔵し, 1つは現在の RAID の代り, もうひとつは rsync で一日一回 backup を検討している.
本来はオットマン状態の PC を机の上にするべきであるが, それは改善しない...