バックアップ復元記5

ddコマンドの実行時間について試したことを記しておく。
最初にマシンのスペックがどの程度影響するかわからないが
確認しておく。

本稼働機
CPU　　Intel(R) Core(TM) i3 M 350  @ 2.27GHz
memory 4GB
USB　2.0

実験機
CPU　　Intel(R) Core(TM) i5-2540M  @ 2.60GHz
memory 8GB(4GB×2)
USB　3.0

内蔵HDDはどちらも500GB

いろいろ調べれば速度を測るスマートな方法があるだろうが
現状、自分が納得できる範囲で
dfコマンドでUSB接続のHDDの使用容量を確認し、時間経過から
おおよその見当をつけた。

最初に行った実験機では、そのことに思いがいたらずひちすら待つまみであった。
また、処理終了後の表示も気に留めなかった。エラーがないこと安心しただけで
速度について大切なメッセージが出ていたとは知らなかった。

前回報告の通り、バックアップに半日以上、リストアも最低6時間はかかった
と思われる。(正確な記憶ではないが)

さて、スペック的には劣る本稼働機で実験機で最初に行ったのと同じHDDで
試してみると、異常に遅い。概略計算とはいえ、丸2日もかかる。
これでは試す価値がないので、処理を中断。

遅い原因は何なのか、実行中のHDDのアクセスランプを見ていて気付いた。
常時連続的に動作している様子がない。時々しかアクセスランプが点滅しない。
内部的な処理をしている時間があると思われる。
理由はおそらくHDDのファイルシステムにあるのだろうと推測した。
HDDは一般的な家電量販店で購入したもので、NTFSでフォーマットされいる。
UbuntuServerはext4なので、最適化とか変換とかしながら書き込んでいるのだろう。
従って時間がかかる。であるならば、HDDをext4のファイルシステムにしてみたら
どうなるかを実際に試してみた。

予想通り、アクセスランプは連続的に点滅し、dfコマンドと経過時間から
本稼働機では5時間と予想され、実際にその通り処理は終了した。
-----------------------------
976773168+0 レコード入力
976773168+0 レコード出力
500107862016 bytes (500 GB, 466 GiB) copied, 17816.7 s, 28.1 MB/s
-------------------------------------------------------------------------------

実験機についても再度行ったところ、予測は2時間ほど。これもその通り終了した。
-----------------------------
976773168+0 レコード入力
976773168+0 レコード出力
500107862016 bytes (500 GB, 466 GiB) copied, 7688.49 s, 65.0 MB/s
-------------------------------------------------------------------------------

時間の差は、マシンのスペックなのか、USBの規格なのか、総合的な結果なのか。
一番の要因が何なのかはわからない。
いずれにしても、実験機のスペック(全体として)で2時間弱という値はddコマンド
の結果としては評価してもよいのではなかろうか。と勝手に思い込む。

ddコマンドについては、これで終了とする。
日々変化するデータをどうバックアップするか、迅速な復旧のために何が必要か
改めて検討してみたい。今回の経験を通して少し、linuxのファイルシステムに
ついて理解が深まった。
それを生かし、難関とは思われるがdumpとrestoreについて
検討してみようと思う。
ただ、Ubuntuには標準でdumpコマンドがインストールされていないのでリストアの際に
desktop版のliveセッションは使えないと思われる。
別の環境を用意する必要がありそうだ。

バックアップ復元記4

ddコマンドによるバックアップ・リストアであるが
ある時点での、ディスクのイメージを作成できるものである。

大まかな流れは
1.　実験機でバックアップを行う。
2.　実験機の内蔵ディスクを交換する。
3.　実験機をUbuntuDesktop版のライブセッションで起動する
4.　バックアップイメージの入ったHDDをUSBに接続する。
5.　USB接続のHDDからリストアを行う。
6.　実験機を内蔵ディスクから再起動する。

今回は実験なので、失敗しても元の内蔵ディスクを戻せば問題ない。
(ファイル名は1つの例)

$ sudo dd if=/dev/sda of=/mnt/USB/sda20190120.img

ifとofを逆にすると大変なことになる。しっかり確認をしてEnterキーを押す。
HDDのアクセスランプが点滅し処理が進んでいる様子。
操作端末のカーソルは処理が終わるまで戻らない。

byobuの別ウィンドウで書き込み容量を確認すると、終了までかなり時間を要する
ことが予想される。

待っている間にいろいろ思うところもあり、確認したいこともいろいろ出てきたが
とにかくリストアまでこぎつけることが先決である。
一番の心配は、内蔵ディスクを交換しているので、uuidの違いで正しくブート
できないことだ。再起動前にuuidを確認したら元のディスクと同じであった。
従って、fstabを書き換えることなく再起動して問題なくブートされた。
同じ型番のディスクだったからなのかどうかはわからない。

さて、待つこと約半日ようやく処理が終了した。(それにしても遅い)

SSHクライアントからサーバーをシャットダウン。
内蔵ディスクの交換は慣れてきたが、慣れが危険、慎重に作業を行う。
(バッテリーをはずすのを忘れずに)

ここからは、PCのディスプレイが故障しているので、テレビに接続して行う。
UbuntuDesktop版のDVDをセットしブート、ライブセッションを立ち上げる。
USBにHDDを接続する。
自動的にマウントされる。マウントポイントは
/media/ubuntu/製品の型番
であった。

いよいよリストアである。それなりの時間は覚悟しているが、祈るような気持ちで
$ sudo dd  if=/media/ubuntu/製品型番/sda20190120.img of=/dev/sda

エラーもなく、順調にアクセスランプが点滅、終わるのを待つだけである。
正確な時間は覚えていないが、6時間以上はかかっていると思う。
処理は夜中だったので、朝目覚めるとアクセスランプは点滅していないので
テレビの電源を入れてみると、カーソルが戻っていた。前後してしまったが
リストア前に、UbuntuDesktopの電源設定でスリープは「無し」にしておいた。

これで、先の通り再起動をかけ、吐き出されたインストールディスクを取り出し
Etnterを押し、見事リストアが成功した。
手順の再確認も含めて、今回の復元記を残そうと思った。

今回は、「できるか」「できないか」結果オーライであったが、問題は時間の
かかり過ぎである。本番では許されない時間である。
処理を待つ間に確認したいと思ったことをこれから試してみることにする。

その結果、この投稿時点で大幅に時間短縮可能であることが確認された。
それは次回に。

 

バックアップ復元記3

 

USB接続のHDDをマウントするのだが、デバイスファイルの扱い方そのものが
いまいち理解できていないので、難しく考えていた。
ともかく、マウントポイントを作成する。
$ sudo mkdir /mnt/USB
とでもしておく。
sdb
sdb1
sdb2
など、最初はよくわからず、uuidでマウントすればいいのだと思い込み
あれこれコマンドで確認をする。
$ ls -al /dev/disk/by-uuid/ | grep sdb
lrwxrwxrwx 1 root root  10  1月 17 17:32 6C02D0C502D09604 -> ../../sdb2
                                                                    ↑
                                                                   uuid
となるので
$ sudo mount /dev/disk/by-uuid/6C02D0C502D09604 /mnt/USB
でマウント完了。
しかし、今となって考えてみればsdb2ということが分かっていれば
$ sudo mount /dev/sdb2 /mnt/USB
でよいことになる。他にいろいろ接続したりしないのであれば変化ないから。
なんとも基本がわかっていない。

 

試しに/home/あたりをdumpしてみようと思う。例えば

$ sudo dump 0f /mnt/USB/home20190120.dump /home

いろいろ表示があり・・・、最後に

DUMP: DUMP IS DONE

となり完了。

早速適当なワークディレクトリにリストアしてみる。

/home以下のディレクトリ構成、ファイルが確認できた。

 

この調子で、/(ルート)を指定して、丸ごとバックアップすればよいのか。

しかし、dumpコマンドの説明には、「ファイルシステム単位のバックアップ」を行うとある。

/dev/sdaを指定するとエラーになる。

/dev/sda2のような指定は可能である。

となると、何らかの理由でシステムが起動しなくなった場合、復旧するためにはハードディスク

全体のバックアップが必要で、そのためには/dev/sda1のバックアップもないといけないのか。

復旧にはパーティションの設定やファイルシステムの作成などもしなくてはならない。

一番不安なのは、bootがきちんとなされるかである。

そんなことを考えると、現在の自身のスキルでは無理があると判断した。

 

従って、ハードディスク全体を丸ごとバックアップできるddコマンドでバックアップする方法に

挑戦することとした。

システム復旧時はUbuntu desktop版のライブセッションから行うこととし、先に報告の通り

復旧に成功した。その詳細は次回以降に。

 

 

バックアップ復元記2

WSLによるUbuntu端末が使用できることになって非常に便利になったことはありがたい。

ただし、端末の操作自体としては不便なこともある。
1つは、Windowsで慣れている右クリックメニューが出ないことである。
不用意に右クリックするとクリップボードのテキストが貼りついてびっくりする。
それと、バックアップやリストアにはそれなりの時間がかかる。

特に今回はシステム全体を対象と考えているのでなおさらである。

端末操作の途中で接続が切れたり、うっかりアプリを閉じたりするとすると困ってしまう。
この二つを解決してくれる方法がある。wslttyとbyobuである。
wslttyは右クリックメニューの問題を解決してくれる。
https://github.com/mintty/wsltty/releases
から最新版を導入した。インストールするとスタートメニューに追加される。
フォントが少し小さいので、設定(option)からtextの設定をしておくとよい。
byobuは複数の端末を使えるもの。複数の端末を利用できるものは他にもあるが

byobuのメリットは元の状態を維持したままデタッチできることだ。
回線が切れたりアプリを閉じたりしても、処理は中断されない。
SSHで再接続してbyobuを実行すれば元の画面が表示される。

 

さて、まずdumpの使い分から試して見ようと思った。
ところが、ダンプコマンドが使えない。

Command 'dump' not found, but can be installed with:

sudo apt install dump

 

えー、何なの?
sudo apt install dump
でいいはず。しかし

-----------------

パッケージリストを読み込んでいます... 完了
依存関係ツリーを作成しています
状態情報を読み取っています... 完了
E: パッケージ dump が見つかりません

------------------

となりできない。メッセージの通りsudo apt install dumpしてるのに。
最初の一歩ではやつまずいてしまった。

パッケージ検索し、いろいろ試したがわからない。

検索の仕方も悪いのかもしれないが依存関係がどうとかもよく理解していないが

とにかく何とかしなくてはいけない。
それでようやくたどり着いたのがこれでdumpがインストール可能に

sudo apt-add-repository universe

よいかのか悪いのかわからないが、これでdumpがインストール可能になった。

メッセージも残しておく。

「すべてのソースファイルに対してディストリビューションの'universe'コンポーネントを有効化しました。」
この意味もよくわからない。基礎的なことはとりあえず後に。
これでdumpとrestoreも使用可能となる。

 

これだけで疲れてしまう。
いよいよUSBにHDDを接続、マウントしdumpの実行だ。
詳細は次回以降に。

バックアップ復元記1

最初に、予備機へのserver環境構築。
インストール直後にやることはいろいろある。
タイムゾーンの設定、日本語環境の設定、各種パッケージのインストールなど。

ファイルサーバーsamba
Webサーバー　apache
データベースサーバー　MySQL　及び　phpMyAdmin
DNSサーバー
メールサーバー Postfix(送信専用)

結構な手間である。従って、万一の時に迅速に復旧できるかが大切である。
さて、ここで失敗に気付く。本稼働機と予備機でファイルを共有できるように、shareフォルダーを通して
行うのだが、同じshareでは区別がつきにくいので、予備機の方は公開名を変更した。
/etc/samba/smb.conf
に共有名を設定。仮に yobiboxとでもしておく。これで本稼働機のshareと区別できる。
そこまでは良かったが、本稼働機と同じ環境ということしか頭になくて肝心のサーバー名も同じにして
しまっていた。ネットワーク上では最初に認識されたものしか正しく認識されない。
予備機のhostnameを変更するが、何故か2回目の再起動で元に戻ってしまう。
1回目の再起動後に
/etc/hostname
を確認すると、既にこの時点で元に戻っている。
web上には
/etc/hosts
の変更も行うような記載がみられるが、どうもこちらは関係ないようだ。(もともと変更していない)
さらに調べると、以下のようにすることで解決することが分かった。
/etc/cloud/cloud.cfg の
preserve_hostname: false
となっている行を
preserve_hostname: true
に変更すると、再起動後に
/etc/hostname
が書き変わることはなくなった。
予備機の環境が整うまでも、何度か電源は落ち、とうとうもともとの不具合であった液晶画面は
何も表示されなくなった。テレビに接続して操作することもしばしば。移動やら配線など何とも大変である。
まあ、再起動してしまえばあとはSSHクライアントから操作できるのでなんとか我慢する。
復旧の手順確認まで頑張って動いてくれるよう祈るばかり。
本題のバックアップと復元は次回からとする。

desktop版再ダウン

つに来る時が来たか・・・。

電源を入れても、すぐに落ちる。何度試しても同じ。HDDを交換してみようと思った。

注文してから納品まで約2週間、期待して交換したが回復せず。HDDもメモリ(4GB×2)もはずし、廃棄を覚悟した。

さて、リモート端末をどうするか。Win7のSSHクライアントもあるが、Linux専用PCが欲しいと思い、中古のPCを購入する。

どんなものが来るか心配であったが、十分満足のいくものであった。Win10 HomeのPCである。

まずは、回復ディスクの作成、バックアップソフトでフルバックアップを取り、何かあってもリカバリーできるようにして、ubuntuのdesktop版をインストールしようとしたが、最初の確認画面が出ただけで何の反応もない。インストール要件を満たしていないのか。無駄にしたくはないので、Win10の操作を一通り確認、現役Win7のPCがダメになった時にも移行できるよう基本的な設定をしておくことにした。その過程で、なぜインストールできないのか情報を得るため「win10　ubuntu　インストールできない」のような条件で検索すると、気になることに気が付く。

それは、win10には「WSL」というものがあるらしい。Windows Subsystem for Linuxでubuntuが使えるというものである。

早速、WSLの有効化設定を行いMicrosoftストアからubuntuをインストールした。

ubuntu desktop版のインストールが成功していれば、全く気が付かないことであったが、失敗してよかった。

これで、快適な環境が得られることとなった。

滞っていたserver構築の続きを行うことにする。構築が進むと、やはり気になるのはデータのバックアップである。

serverがダウンすると影響が大きいため、早めの対策が必要である。しかし、linuxマシンのバックアップなど経験もなく市販の個人向けバックアップソフトも対応について具体的な記載がなくどうしたらよいか全く見えない。

まずは、サーバーの予備機を用意しいろいろためしてみようと思った。そこでまた廃棄予定のPC登場である。HDDとメモリを戻し、ubuntu serverのインストール用usbメモリをセットし、落ちても落ちてもしつこく電源を入れなおす。何の気まぐれがついにインスールを開始、無事完了。いつ壊れてもおかしくない状態なので、早くバックアップの方法を検討しなくてはいけない。

購入した同じ型番のHDDがあるので、失敗しても交換すれば元に戻る。何回でも安心して試すことができる。

そして本日早朝、何度かの失敗ののちめでたく復元に成功。

途中経過も含め、備忘録を兼ねてバックアップ復元記を残しておこうと思う。

1/5のwin10中古PC納入から約3週間、悪戦苦闘の詳細は、次回以降。