スポンサーサイト

上記の広告は1ヶ月以上更新のないブログに表示されています。
新しい記事を書く事で広告が消せます。

Synology製NASのデータ復旧(サルベージ)

引き続き、Synology DS213jネタです。

SynologyNASに入れているHDDはLinux等にマウントしてデータを取り出すことができるの?

本番導入にあたり、気になるのが本体故障時にもデータを取り出すことができるか。
私の中ではこれは重要です。
「後継機、同等機にそのままディスク突っ込めば大丈夫です!」っていわれても、いやいや、そうじゃない。
その時にそういう機種があるか、経済的に買えるか(笑)などの事情を考えるとやはり一般的な環境でデータを吸い出せる事がとても大切です。
理想は、HDDケースなどでPCに接続したら普通に読み出せることですね。
※ちなみに、Intelの"ラピッドストレージテクノロジ"の場合できます。

まぁ、買った後にできなかったらどうするのって?さすがに買う前にちょっとは調べてます。ただ、Synologyはあまり日本語でも情報がなかったのでいささか不安ではありましたが。(※後日日本語のものも見つけました。記事いちばん下。)
サルベージだと勝手に思っていましたが、英語だと「retrieve」とか「recover」みたいです。このキーワードにたどり着くまでに時間かかったww

参考にしたサイト
 ・How can I recover data from my DiskStation using a PC?
 ・How to retrieve data from RAID Volumes on Linux


どうやら、Linuxでごにょごにょやると、データを取り出すことができるようです。

Ubuntu12.04LTSで試したので、一応メモしておきます。
手順に従って、LiveCDで試しました。





1.NASから取り出したHDDをすべてPCに接続する


SATAポートがいっぱいあるPCを用意しなくても、SATA⇔USB変換ケーブルや、SATA対応HDDケースなどがあればOK。



2.LiveCDでUbuntu12.04を起動


Ubuntuを試すをクリックすればOK。(省略)



3.必要ソフトのインストール


Ubuntuでコンソール(Ctrl+Alt+T)を起動し、以下のソフトをインストール

 ① sudo apt-get update
 ② sudo apt-get install mdadm
 ③ sudo apt-get install lvm2

②のmdadmインストール時に、メールサーバの設定が聞かれますので、「設定なし」を選びます。

salv1.png

salv2.png



4.RAIDボリュームのマウント

コンソールからrootになって、下記コマンドを実施。
$sudo -i
#mdadm -Asf && vgchange -ay
mdadm: /dev/md/Abu:2_0 has been started with 1 drive (out of 2).
Found duplicate PV zO4gGtnsKPwZ7QWLnstGLgELkgLnVfyW: using /dev/md127 not /dev/md126
1 logical volume(s) in volume group "vg1000" now active


こんな感じのメッセージが出てくる。
うまく行かない場合は、HDDを一度接続しなおしたらうまく行った。



5.ディレクトリの確認


ここまでうまく行くと、ファイルマネージャで開くと左側に、RAIDボリュームが表示される。
これを開くと、通常のディレクトリと同じに扱えるのでここからデータを吸い出す事が可能です!

salv3.png



ちなみに、手順ではすべてのディスクを接続しなさいと書いて有りますが、HDD2台でのSHR(SynologyHybridRaid)の場合1台でもマウントできました
※試してないですがRAID1でも同じだと思います。


とりあえず、懸念事項のハード故障時のデータサルベージ、復旧が可能であることがわかって一安心。
まぁ、ここでダメだったとしてもいまさらどうするんだ、って話ですがww



次は、ディスクを大きくした時の動作を確認したいと思います。



続きを読む

スポンサーサイト

NAS購入 -Synology DS213j買っちゃいました-

Synology DS213jを購入!


ついに本格的?NASを買ってしまいました。

今まで、古いCorei7で組んだ自作PCに、IntelのラピッドストレージテクノロジでRAID1を組んでいましたが、
・ 普段いない寝室にPCが置いてある
・ 消費電力が大きくかつ爆音PCの為、常時稼働が困難
というため、データアクセスのためにはいちいち寝室に行ってPCを起動する必要がありました。

なので、RaspberryPiにUSB-HDDを接続してPCのデータをRaspberryPiのHDDにミラーして通常時はそちらを参照しに行くという運用をしていました。
しかし、データが複数分散されるうえにコピーに時間がかかるなどが少し気になっていました。
NASは以前から気になっていたのですが、QnapやNetgeerなどのNASが有名でしたが、私にはちょっと高価で少し躊躇していました。
そんな折、synologyというメーカのNASを見つけて調べているうちに興味が出てきました。
台湾のメーカーらしく、割と後発らしいですが調べるとソフトウェアにいろいろ力を入れているとか、いないとかw

オフィシャルサイト
製品サイト


必要機能・選定のポイントは以下

保護するべきデータ
写真、ビデオ、音楽データ、動画データなどありますがお金を出せば手に入るデータは最悪あきらめてもよいが、写真・ビデオ(ホームビデオ)のデータはまもる。

必須機能

・ RAID1ないしはそれ相当のRAIDシステムが構築可能
・ RAIDケースが故障した際にもデータの取り出し(サルベージ)が可能であること
・ 将来的にディスクを拡張してサイズを大きくできる事(現在1TのRAID1)
・ 省電力であること
・ 十分静かであること

改めて書くと要件すくなっ!(Buffaloとかでもいいんじゃね?)


選定のポイント

・ メディアサーバの機能を有する事
・ Androidや、iOSからも参照・操作できること
・ AirPlayやDLNAでの外部装置への再生等が可能
・ HDDが最低2台搭載可能
・ 経済事情にあった価格であること

AirPlayやDLNAへの出力とそのコントロールをAndroidやiOSから操作できるという機能に惹かれました。
そのほかにも使う、使わないはともかくとしていろいろな機能があります。(他メーカーとそんなに比較してないwwwww)


現在、自宅でRaspberryPiのHDDに入っている音楽データや動画を再生する際には、Raspbmcで再生する形になっています。
以前の投稿で入手したUSB-DACで外部スピーカーに接続しています。(現在はHDMIでTVのスピーカーから出力していますが。)いずれにしてもリビングで音楽を手軽に聞くには楽なのですが、寝室などで奥さんが子供に音楽を聞かせたいという用途にはすごく不向きでした。

そ・こ・で、AirPlay対応のスピーカーに目を付けました。で、このスピーカーにAirPlay出力が可能であるこの機能に着目したわけです。
これが決め手になりました。(まぁ、この機能は他メーカーも持っているわけですがww)



最終的に次の二つですごく悩みました。
① DS213j
② DS213+
私的に気になった違いは、前面にあるUSBポートと、ホットスワップ対応か否か。(ほかにもありますが詳しくはオフィシャルサイト見て。)
あと、価格www

でホットスワップは特に惹かれたのですが、別に家庭内だしHDD交換の時は止めても問題ないだろうという判断。
前面にあるUSBポートは、ボタン一つでSDカード等をバックアップ取れる機能に最後まで悩みましたが、自分でフォルダ整理したいしという負け惜しみと価格に負けてDS213jにしました。
吉と出るか凶と出るか。

正直、書き込み/読み込み速度徒かはそれほど興味がないので調べませんwww。興味ある人はこの辺でも見ればいいんじゃない?(適当)

というわけで、我が家(にとって)の重要データはSynologyへ全て任せることにしました。
10年、いや、5年くらいは頑張って利用していければと思います。まぁ、壊れなくても新しい機能に惹かれちゃうんでしょうけど。

写真のレビューとかはしませんが、興味がある人は「ASCII.jp DS212j」で検索して出てくる記事の写真とほとんど変わりませんので、そちらを参考にしてはいかがでしょう?(オイw)


しばらく、稼働までの間いくつかテストをしてから、データの移行を行おうと思います。

OpenVPNが繋がらない!

前回前々回でリモートから自宅に接続するためのVPN環境に挑戦してきました。

参考にしている人がいるかは不明ですが、マネしたけどうまくいかないという方、OpenVPNでリモートクライアントからVPN接続できないという方。
もしかしたら参考になるかもしれません。


DD-WRTで設定したOpenVPNはUDPの1194番を利用してVPNセッションの接続を試みます。
「クライアントが、パケットフィルタを実施しているNATルータの配下にいる環境」の場合、ルータで外部→内部向けのUDP/1194を通過するようにフィルタが設定されていないとVPNのセッションを確立できません。これは、大雑把にいうとUDPはセッション確立という概念がないため、パケットフィルタ機能だけでの制御は結構困難なためです。(頑張ればできます)

そこで、セッション確立という概念があるTCPを利用することでこれを回避できるケースがあります。
一般的に、ユーザがインターネットに使うネットワーク環境では内部から外部向けのTCPセッションの戻りは許可する設定になっていることが多いです。これをうまく使います。
※インターネットでWebが見られる環境なら、ほぼ大丈夫なはず。(管理者の設定にもよるため確実とは言えませんが)
逆にWebすらも制限されているようなネットワークでは結構絶望的な気がします(笑)
・外部から内部向けでTCPのAckフラグが設定されているパケットも拒否するフィルタ
 (いわゆる、内部から外部向けのTCPセッション確立を認めないフィルタ)



--多少細かい説明--
UDPはホスト間(この場合クライアントとOpenVPNサーバ)で事前のセッションの確立を行いません。
一般的なFirewall(家庭用ブロードバンドルータでも対応しているものはある)であれば、ステートフルインスペクション機能によりUDPの戻りもFirewallが動的に許可しますが、対応していないNATルータでパケットフィルタによって制御しているようなネットワーク環境にいる場合は制限が出てきます。
UDPの戻りパケットを明示的に許可してあげないといけないですが、たくさんあるUDPポートを開けてることは少ないので場合によってはネットワーク管理者に依頼して変更してもらう必要があります。



というわけで、OpenVPNサーバとのセッション確立にTCP/1194を利用することにより回避する方法です。


■■ テスト環境 ■■
・OpenVPNサーバ機器:Buffalo WHR-HP-G54 
・OpenVPNソフトウェア:DD-WRT(v2-sp vpn) with OpenVPN
・OpenVPNクライアント:Ubuntu12.04


■■ 前提 ■■
・DD-WRTへOpenVPNで接続できる環境ができていること。
できてない場合はこちらを参考にしてみてください。





1.DD-WRT側のOpenVPNサーバ設定


・Webブラウザで、ルータの管理画面にアクセスします。
・[ネットワーク > PPTPサーバ/クライアント]の順にメニューをたどる。
・OpenVPNデーモンの中の、「OpenVPN Config」の設定を変更します。

push "route 192.168.1.0 255.255.255.0"
push "dhcp-option DNS 192.168.66.1"
server 192.168.66.0 255.255.255.0

dev tun0
proto tcp ←udpをtcpに変更する。

keepalive 10 120
dh /tmp/openvpn/dh.pem
ca /tmp/openvpn/ca.crt
cert /tmp/openvpn/cert.pem
key /tmp/openvpn/key.pem

# Only use crl-verify if you are using the revoke list - otherwise leave it commented out
# crl-verify /tmp/openvpn/ca.crl

# management parameter allows DD-WRT's OpenVPN Status web page to access the server's management port
# port must be 5001 for scripts embedded in firmware to work
management localhost 5001




2.DD-WRT側のフィルタ設定


DD-WRTのWeb画面で「管理->コマンド実行」の順にたどり、実行コマンドに以下を張り付け
※ここも自分の環境と合わせてください。


iptables -I INPUT 1 -p tcp --dport 1194 -j ACCEPT
iptables -I FORWARD 1 --source 192.168.66.0/24 -j ACCEPT
# These next two lines may or may not be necessary.
# I (dereks) did not need them, but bmatthewshea did.
# Thus, we include them so that this works for more people:
iptables -I FORWARD -i br0 -o tun0 -j ACCEPT
iptables -I FORWARD -i tun0 -o br0 -j ACCEPT



3.クライアントPC側の設定

OpenVPNクライアント側の"client.conf"を設定してあげます。
私は、"~.openvpn"配下に配置しているので、これを編集します。編集箇所は、

remote 192.168.100.253 1194

client
remote-cert-tls server
dev tun0
proto tcp

resolv-retry infinite
nobind
persist-key
persist-tun
float
;comp-lzo

#If the pushed routes appear not to be added on windows hosts, add the following:
route-delay 30

ca /etc/openvpn/ca.crt
cert /etc/openvpn/client1.crt
key /etc/openvpn/client1.key




4.サーバの確認(DD-WRT(OpenVPN))

サーバでのサービスポートを確認します。
ルータにSSHでログイン等を行なって、以下のコマンドを実行。
Port1194がTCPで待ち受けていることを確認する。

root@DD-WRT:~# netstat -an
Active Internet connections (servers and established)
Proto Recv-Q Send-Q Local Address Foreign Address State
tcp 0 0 127.0.0.1:5001 0.0.0.0:* LISTEN
tcp 0 0 0.0.0.0:1194 0.0.0.0:* LISTEN
tcp 0 0 0.0.0.0:80 0.0.0.0:* LISTEN
tcp 0 0 0.0.0.0:53 0.0.0.0:* LISTEN
tcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN
tcp 0 0 0.0.0.0:23 0.0.0.0:* LISTEN
tcp 0 0 192.168.100.1:22 192.168.100.131:53031 ESTABLISHED
tcp 0 0 192.168.123.253:1194 157.82.12.10:7474 ESTABLISHED
udp 0 0 0.0.0.0:53 0.0.0.0:*
udp 0 0 0.0.0.0:67 0.0.0.0:*
raw 0 0 0.0.0.0:255 0.0.0.0:* 255
Active UNIX domain sockets (servers and established)
Proto RefCnt Flags Type State I-Node Path
unix 2 [ ] DGRAM 3745920




5.接続確認

クライアントで接続してみます。ターミナルから実行。

$ sudo openvpn client.conf 
Thu May 23 09:54:15 2013 OpenVPN 2.2.1 i486-linux-gnu [SSL] [LZO2] [EPOLL] [PKCS11] [eurephia] [MH] [PF_INET6] [IPv6 payload 20110424-2 (2.2RC2)] built on Mar 23 2012
Thu May 23 09:54:15 2013 NOTE: OpenVPN 2.1 requires '--script-security 2' or higher to call user-defined scripts or executables
Thu May 23 09:54:15 2013 Control Channel MTU parms [ L:1543 D:140 EF:40 EB:0 ET:0 EL:0 ]
Thu May 23 09:54:15 2013 Socket Buffers: R=[87380->131072] S=[16384->131072]
Thu May 23 09:54:15 2013 Data Channel MTU parms [ L:1543 D:1450 EF:43 EB:4 ET:0 EL:0 ]
Thu May 23 09:54:15 2013 Local Options hash (VER=V4): 'db02a8f8'
Thu May 23 09:54:15 2013 Expected Remote Options hash (VER=V4): '7e068940'
Thu May 23 09:54:15 2013 Attempting to establish TCP connection with [AF_INET]x.x.x.x:1194 [nonblock]
Thu May 23 09:54:16 2013 TCP connection established with [AF_INET]x.x.x.x:1194
Thu May 23 09:54:16 2013 TCPv4_CLIENT link local: [undef]
(中略)
Thu May 23 09:54:19 2013 Initialization Sequence Completed

TCPでのトンネルが確立しました。


念の為、クライアントでインタフェースを確認。
$ sudo ifconfig
(略)
tun0 Link encap:不明なネット ハードウェアアドレス 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
inetアドレス:192.168.66.6 P-t-P:192.168.66.5 マスク:255.255.255.255
UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1500 メトリック:1
RXパケット:0 エラー:0 損失:0 オーバラン:0 フレーム:0
TXパケット:0 エラー:0 損失:0 オーバラン:0 キャリア:0
衝突(Collisions):0 TXキュー長:100
RXバイト:0 (0.0 B) TXバイト:0 (0.0 B)

となっており、ちゃんとトンネルI/Fが表示される。
引き続き、クライアントのルーティングの確認を行う。
$ netstat -rn
カーネルIP経路テーブル
受信先サイト ゲートウェイ ネットマスク フラグ MSS Window irtt インタフェース
0.0.0.0 10.82.12.254 0.0.0.0 UG 0 0 0 wlan1
10.82.12.0 0.0.0.0 255.255.255.0 U 0 0 0 wlan1
192.168.66.1 192.168.66.5 255.255.255.255 UGH 0 0 0 tun0
192.168.66.5 0.0.0.0 255.255.255.255 UH 0 0 0 tun0
192.168.1.0 192.168.66.5 255.255.255.0 UG 0 0 0 tun0

接続先のネットワークの転送先がtun0に向いていることを確認する。

以上で完了。



これで、UDPのフィルタが開いていない環境からのOpenVPN接続の確率が可能となります。
うまく行かないかたは、ぜひTCPを試してください。
ちなみに、TCPにすると多少遅くなるとのことなので可能であればDefaultのUDPを推奨します。

※ 実環境でのログから記事のためにちょっとアドレスを変えたりしていますので、細かい間違いは無視してください。必要な箇所は、各項目でTCPに変更する箇所です(赤字)。
プロフィール

Author:Opecha-DaDa
ニッチな技術メモ的なブログになりつつありますが、だからこそあなたのお役に立てる内容があれば幸いです。

最新記事
最新コメント
最新トラックバック
月別アーカイブ
カテゴリ
検索フォーム
RSSリンクの表示
リンク
ブロとも申請フォーム

この人とブロともになる

QRコード
QR
上記広告は1ヶ月以上更新のないブログに表示されています。新しい記事を書くことで広告を消せます。