※当サイトの記事には、広告・プロモーションが含まれます。

Linux環境でWindowsの共有フォルダをマウント、からの~、robocopyを試してみる

f:id:ts0818:20200606204747j:plain

ドリーDolly1996年7月5日 - 2003年2月14日)は、世界初の哺乳類体細胞クローンであるスコットランドロスリン研究所で生まれ育ち、6歳で死ぬ。ドリーの誕生は1997年2月22日に発表された。

ドリー (羊) - Wikipedia

ドリーという名前は乳腺細胞由来にちなんで、飼育係がドリー・パートン巨乳を称えて提案したものである。ドリーは体細胞のを除核した細胞に移植する技術によって誕生した。ドリーは1996年に6歳の雌羊の細胞からクローンされ、今日まで続く議論の的となっている。

ドリー (羊) - Wikipedia 

⇧ クローンの発祥と言えば、羊の「ドリー」が有名ですが、ネーミングの由来が全く研究に携わっていない人物のものってのが衝撃...どうもボクです。

クローンを題材にした作品も多いようですが、

アイランド (字幕版)

アイランド (字幕版)

  • 発売日: 2013/11/26
  • メディア: Prime Video
 

⇧ 「アイランド」とかって、2005年の作品だったんですね、15年経ってるのか~、ユアン・マクレガースカーレット・ヨハンソンが若い!

舞台設定は、2019年だったんですよね。

 

2020年現在、クローン技術ってどんな状況なんですかね?

www.riken.jp

本研究により、タンパク質をコードしない小さなRNAであるmiRNAの正確な遺伝子発現制御が、胎盤形成で大きな役割を果たすことが明らかになりました。ヒトを含む霊長類でも胎盤で発現しているmiRNAクラスターの存在が報告されており、同じように重要な役割を持っていると予想されます。本成果は、ヒトの妊娠中の胎盤異常の原因解明やマーカー遺伝子の開発などにつながると期待できます。

体細胞クローンマウスの胎盤異常の原因を解明 | 理化学研究所

また、20年以上にわたり未解明だった体細胞核移植クローンの胎盤形態異常の原因が初めて明らかになりました。本成果は今後、他動物種における胎盤異常の原因究明や、より質の高いクローン個体の作出に役立つと期待できます。

体細胞クローンマウスの胎盤異常の原因を解明 | 理化学研究所

⇧ ここ最近で、かなり進展があったみたい。

 

By the way、ファイルのコピーしたいこと、あるあるだよね~。

robocopyコマンドというものが良いらしいですと。

blog.serverworks.co.jp

⇧ 上記サイト様の図による解説がむちゃくちゃ分かりやすいです、親切な説明ありがたいです。

 

あと、オプションの問題点については、 

milestone-of-se.nesuke.com

うーん、マイクロソフトの "すぐ"って言葉の定義、いいね!2009年12月21日~2015年11月2日現在でまだ修正されていません。6年!

Monday, November 02, 2015 10:40 PM

robocopy の速度向上ノウハウ~遅い原因と見直すべき5点~│SEの道標

PowerShellで解決策を見つけたけどあんまりエレガントな方法じゃないや。。問題解決まだー?

Wednesday, January 17, 2018 2:37 PM

robocopy の速度向上ノウハウ~遅い原因と見直すべき5点~│SEの道標

⇧上記サイト様が詳しいです。

マイクロソフトさん、安定の不親切さ。

最新の投稿によると、

social.technet.microsoft.com

Now we are at year 2020 with corona. It's 10 years and counting "soo

Edited by Meitzi Monday, May 18, 2020 6:38 AM

Robocopy's /MT option disables /NP option

⇧ まだ解決されとらんようね...10年経つってさ...

もうマイクロソフトさん無かったことにしようとしてるんじゃないかね、これ。

何とか頑張って欲しいものですが...10年経っても音沙汰なしってことは、望み薄ですかね、Oh, my gosh...

というわけで、robocopyを使ったファイルコピーにレッツトライ~。

 

Linux環境でWindowsの共有フォルダをマウントするには

Windows」と「Linux」はOSが異なるので、ファイルシステムも異なりますと。

で、「Windows」の「共有フォルダ」は「SMB」って共有プロトコルで実現してるようなので、

turningp.jp

LinuxWindows の共有フォルダにアクセスするにはまず「cifs-utils」とインストールする必要があります。

LinuxからWindowsの共有フォルダにアクセスする方法 | TURNING POINT

なぜ「yum install cifs-utils」が必要かというと、LinuxWindows のファイル共有プロトコルである「SMB」を理解できるようにするためです。

LinuxからWindowsの共有フォルダにアクセスする方法 | TURNING POINT

SMB は元々 Windows 以外が利用できないプロトコルですが、後に Windows 以外も利用できるようになりました。それに伴い名前が SMB から CIFS(Common Internet File System)と変わっていたんですが、また SMB に戻ったという経緯があります。

LinuxからWindowsの共有フォルダにアクセスする方法 | TURNING POINT

⇧ 上記サイト様にありますように、Linuxで「CIFS」を利用できるようにってことみたいです。

 

souiunogaii.hatenablog.com

laboradian.com

⇧ 上記サイト様を参考にさせていただきました。

  1. Windows環境(ホストOS)
    • 共有オプションの確認
    • 共有フォルダを作成
  2. Linux環境(ゲストOS)
    • 「CIFS(Common internet File System)」を利用できるようにする
    • Windows環境で用意した共有フォルダとLinux環境のフォルダをマウントする

 って流れになるかと。

 

共有オプションの確認

Windowsのホームボタンをクリックして、「設定」アイコンをクリック。

f:id:ts0818:20200606153336p:plain

「ネットワークとインターネット」を選択。

f:id:ts0818:20200606153448p:plain

「共有オプション」を選択。

f:id:ts0818:20200606153604p:plain

自分の場合、でデフォルトの状態は以下のキャプチャ画像のような内容でした。

f:id:ts0818:20200606153714p:plain

f:id:ts0818:20200606153919p:plain

f:id:ts0818:20200606152813p:plain

まぁ、とりあえずは、デフォルトの状態のままにしておきます。

 

共有フォルダを作成

共有フォルダを作成していくわけですが、

laboradian.com

フォルダは2種類のアクセス権を持ちます。

  1. ファイルシステムのアクセス権
  2. 共有アクセス権

※ ファイルには「共有アクセス権」がないようです。

Windows 10 でファイル・フォルダを共有する方法 | ラボラジアン

 共有アクセス権」というのは、他のコンピュータからのアクセスされた時にまず最初に照合が行われるアクセス権です。こちらは、フォルダのみの設定となります(ファイルにはありません)。

Windows 10 でファイル・フォルダを共有する方法 | ラボラジアン

⇧ とあるように、「共有アクセス権」ってのが設定されて、初めて「共有フォルダ」というものになるようです。

Windowsの場合は、主に、2つのやり方があるようですが、上記サイト様を参考に「共有ウィザードを使う方法」で設定してみたいと思います。

そのためには、「フォルダーオプション」の設定を確認する必要があるようです。

エクスプローラー」の「ファイル」タブを選択して表示される「オプション」をクリック。

f:id:ts0818:20200606162200p:plain

「表示」の「詳細設定:」で「共有ウィザードを使用する(推奨)」にチェックが付いていればOKのようです。

f:id:ts0818:20200606162809p:plain

 

「フォルダーオプション」の確認が終わったら、適当な場所にディレクトリを作成で。

f:id:ts0818:20200606161151p:plain

作成したディレクトリを選択した状態で右クリックし「プロパティ(R)」を選択。

f:id:ts0818:20200606161249p:plain

「共有」タブの「共有(S)...」をクリック。

f:id:ts0818:20200606163225p:plain

自分自身のアカウントに共有するから、「追加」はせず、「共有(H)」で良いんかな?

f:id:ts0818:20200606163525p:plain

特に何もしなくて良かったみたい。「終了(D)」で。

f:id:ts0818:20200606163620p:plain

何か、

f:id:ts0818:20200606164252p:plain

⇧ 「C:\」配下のディレクトリは「フォルダ」作成した時点で「共有フォルダ」になってるらしい。

Windowsのマシンが複数台あって、別のマシンから「共有フォルダ」にアクセスするって状況じゃないと分かり辛いってことですかね。

 

とりあえず、作成したディレクトリの片方に、テキストファイルを作成しておきます。

f:id:ts0818:20200606184923p:plain

 

Linux側で「CIFS(Common internet File System)」を使えるようにする

まずは、仮想マシンの作成ですかね。

仮想マシンについては、一応、2台準備するということで。

自分は、

ts0818.hatenablog.com ts0818.hatenablog.com

⇧ この時に作成した環境を利用することにしますので、仮想マシン作成の部分は割愛させていただきます。

仮想マシンが準備できたらば、起動しておきます。

f:id:ts0818:20200606170641p:plain

Kubernetesを試した影響で、3台動いてますけど、2台あればOKです。

仮想マシンにログインで。 

f:id:ts0818:20200606171322p:plain

「cifs-utils」をインストールします。スーパーユーザー(root ユーザー)に切り替えるか、sudoをコマンドに付けるかして、以下のコマンドを実行。今回は、スーパーユーザー(root ユーザー)に切り替えてます。

dnf install cifs-utils

f:id:ts0818:20200606182255p:plain

f:id:ts0818:20200606182359p:plain

インストールできたようです。

もう1台の仮想マシンも同じように、「cifs-utils」をインストールしておきます。

 

Linux環境でWindowsの共有フォルダをマウント

Linux環境に、マウント用のディレクトリを作成します。

f:id:ts0818:20200606182810p:plain

んで、マウントの際ですが、VirtualBox仮想マシンを作成している場合、Windows側のディレクトリのパスは、デフォルトだと、マシン名じゃなくてIPアドレスにしてないとマズイらしい。

mount -t cifs -o user=[Windowsのログイン時のユーザーのアカウント],password=[Windowsのログイン時のユーザーのパスワード] //[ipconfigで確認したIPアドレス]/[Windows側でマウントしたいディレクトリ] [Linux側でマウントしたいディレクトリ]

f:id:ts0818:20200606184604j:plain

⇧ マウントできました。

IPアドレスは、Windows側で、ipconfigで確認できるかと。

f:id:ts0818:20200606184627j:plain

同じ感じで、もう一方の仮想マシンでもWindowsの共有フォルダとマウントしておきます。

 

robocopyを試してみる

そんでは、Windowsの共有フォルダに作成していたテキストファイルを、もう一方の共有フォルダにrobocopyというコマンドでコピーしてみます。

その前に、Windowsの共有フォルダの中身を今一度確認。「ネットワーク」のほうから確認してみます。

■vm01_share(\\TOSHINOBU-PC\Users\Toshinobu\Desktop\soft_work\vm01_share)

f:id:ts0818:20200606190349p:plain

■vm02_share(\\TOSHINOBU-PC\Users\Toshinobu\Desktop\soft_work\vm02_share)

f:id:ts0818:20200606190448p:plain

 

robocopyコマンドについては、windows 10 ならデフォルトで使えるコマンドらしいです。自分は、Windows 10 Home の64bit版を使ってるのですが、robocopyコマンドありました。 

f:id:ts0818:20200606191441p:plain

 

どうやら、

blog.ver001.com

ようやく本題ですが、Windowsには昔から、それこそWindows 2000の時代からrobocopyというツールがあります。OSに標準搭載されたのはXPからですが、2000の頃からMS社内では使われていました。

Windowsのバックアップはrobocopyが簡単便利で早い

⇧ 上記サイト様によりますと、Windows XP の時代から標準搭載されてたようですね。

ちなみにrobocopyのroboはrobotではなく、robust(堅牢)の略。

Windowsのバックアップはrobocopyが簡単便利で早い

⇧ な~る、「ジャイアントロボ!」的な「robot」って意味では無いんですね。

 

そんでは、早速、試してみますか。オプションがむちゃくちゃ多いんですが、一番基本的な形は、

robocopy [移行元パス] [移行先パス] [オプション]

⇧ みたいな感じらしい。

オプションがかなり癖が強いらしいので、本番で使う際は要チェックみたいです。

実行してみた。

f:id:ts0818:20200606194347p:plain

 

結果

■vm01_share(\\TOSHINOBU-PC\Users\Toshinobu\Desktop\soft_work\vm01_share)

f:id:ts0818:20200606194541p:plain

■vm02_share(\\TOSHINOBU-PC\Users\Toshinobu\Desktop\soft_work\vm02_share)

f:id:ts0818:20200606194437p:plain

 

仮想マシン側もちゃんと、vm02_shareとマウントしたディレクトリにテキストファイルがコピーされているのを確認でき、反映されていることが分かりました。

■vm01_shareとマウントしたディレクト

f:id:ts0818:20200606194623p:plain

■vm02_shareとマウントしたディレクト

f:id:ts0818:20200606195140p:plain

 

本当は、ホスト(ここではWindows側のこと)のマシンも別々にしてからのネットワーク経由でのrobocopyで大容量ファイルのコピーを試してみたかったんですが、環境がね...

ノートパソコン1台しか家に無いしな...

www.itmedia.co.jp

Raspberry PI とか購入しようか、でも、Raspberry PI って大容量ファイルのを収めれるほどのストレージを持ってるとは思えないんよね... 

まぁ、何て言うか、財力がものを言う業界よね...

パソコンもう1台欲しい~、せめて一家に2台でしょ!

 

さて、ボヤキが出てきたところではありますが、robocopyに話を戻して、本番環境では、移行するファイルはTB級の大容量になることが一般的だとは思いますが、大容量のファイルで実行した際にエラーとか出なければ、バックアップする際にも利用できそうですかね?

あとは、速度とかが気になってくるところですよね。

server-setting.info

また、ここでは比較していませんが、有線LAN(1Gbps) で2台のPCを接続し、コピーするのも USB 2.0 で接続するよりは、かなり早いこともわかっています。(参考まで)

1TBのDiskコピーにかかる時間を計算してみる | レンタルサーバー・自宅サーバー設定・構築のヒント

結局、色々と個人的にも試した感じでは、SATAの接続が可能なら両者接続の上、コピーするのが 一番 良さそうです。
それができない場合は、有線LAN(1Gbps)での接続が可能なら2台のPCでコピーするのも良いかと思います。

1TBのDiskコピーにかかる時間を計算してみる | レンタルサーバー・自宅サーバー設定・構築のヒント

⇧ 上記サイト様によりますと、「SATA接続」が最も高速で、それができない場合は、「有線LAN接続」によるネットワーク越しのコピーが速度的には早いんですかね?

ネットワークが要になってくるんですかね。

 

www.orangeitems.com

わざわざ計算しませんが、14TBのデータをネットワーク転送しようものなら、バックアップだけで数日かかる。クラウドになんてもってのほか。

ファイルサーバーの憂鬱 - orangeitems’s diary

⇧ マジっすか...

時間がかかるのはどうしようも無いということなんですかね...

2020年6月9日(火)追記:↓ ここから

ちなみに、

qiita.com

⇧ 一度、開始したrobocopyコマンドをどうやって止めるかと言うと、robocopyとして動き出してしまったタスクを kill するしか無さ気らしい...う、う~ん...

2020年6月9日(火)追記:↑ ここまで

2020年6月8日(月)追記:↓ ここから

そういえば、robocopyコマンドを使う時は、コマンドプロンプトじゃなくてPowerShell を使ったほうが良さ気っぽい。

というか、

news.mynavi.jp

Rich Turner氏のツイートを要約すると次のとおり。

MS開発者がツイート「コマンドプロンプトじゃなくPowerShellを使ってね」 | マイナビニュース

⇧ Oh, my gosh...

MicrosoftWindows Terminal 1.0の公開と同じ時期にWindows PowerShellの後継となる「PowerShell 7」を公開している。Microsoftとしては今後はWindows TerminalとPowerShell 7をシェルとして使ってほしいと考えている。

MS開発者がツイート「コマンドプロンプトじゃなくPowerShellを使ってね」 | マイナビニュース

⇧ どっちも、クセが強そうなのよね...

By the way、通常のWindowsとかだと、「設定」の、

f:id:ts0818:20200608204146p:plain

「ネットワークと共有センター」の、

f:id:ts0818:20200608204106j:plain

「接続:」のインターネットで選択できるのを選択して、

f:id:ts0818:20200608204858j:plain

転送速度ってのが確認できるらしいんだけど、

f:id:ts0818:20200608204841j:plain

VDI(Virtual Desktop Interface)なんやらのように、仮想デスクトップのような環境の場合、そもそも「ネットワークと共有センター」にアクセスできなく制御されてる時があるんですな。(実際、いまの職場の環境がVMWareとかで仮想デスクトップ環境を実現してるらしいんだけど、原則ネットワークを有効にするが禁止されとるっぽい。)

そんな場合は、「状態」「ネットワークのプロパティを表示」から、

f:id:ts0818:20200608210128j:plain

「リンク速度(送受信)」で確認できるっぽい。

f:id:ts0818:20200608210258j:plain

VirtualBox仮想マシンネットワークアダプターだと「リンク速度(送受信)」が表示されとらんけどね...

f:id:ts0818:20200608210242j:plain

 

ちなみに、

note.cman.jp

bps」は1ビット単位、「B/s」は1バイト単位となり、「1バイト=8ビット」のため、「bps」は「B/s」の8倍、「B/s」は「bps」の1/8倍となります。
このため「100Mpbs回線=12.5MB/s回線」となり、単位の違いだけで同じ意味を表しています。

回線速度(転送速度、通信速度)の単位「bps」「B/s」変換

⇧ とあることから、「回線速度」は「リンク速度(送受信)」と考えて良さそうですかね、職場の同僚の方にお聞きしたところ、「回線速度」は「リンク速度(送受信)」と考えても良さ気とアドバイスをいただきましたので。

すみません、

fuji-wifi.jp

リンク速度とは、WiFiのみの通信速度のことです。

具体的には、無線LANルーターと接続デバイスの間の速度のことを指します。

単位は「Mbps(megabits per second)」で表されます。

リンク速度は、普段よく気にされるいわゆる回線速度(通信速度)とは別物で、プロパイダや接続先のサーバーの強度などとは関係ありません。

しかし、回線速度を含めたWiFiの速度全てに関わる重要なもので、決して軽視することはできないものです。

WiFiのリンク速度とは?確認する方法や遅い時の対処法も紹介 - FUJIログ通信

⇧ 違ったみたいですが、回線速度を含めたWiFiの速度全般に関わってくるんだそうな。

ネットが快適に使えていない場合、回線速度やプロパイダに目を向けがちですが、WiFiの根底となる速度はリンク速度です。

WiFiのリンク速度とは?確認する方法や遅い時の対処法も紹介 - FUJIログ通信

リンク速度が遅ければ、そのほかの要素が優れていたとしても、回線全体が低速となってしまいます

WiFiのリンク速度とは?確認する方法や遅い時の対処法も紹介 - FUJIログ通信

⇧う~ん、有線LANにしたら、また話は変わってくるのかな?

まぁ、とりあえず、「リンク速度(送受信)」で考えてみますか。

 

私の自宅の環境では「リンク速度(送受信)」が「86Mbps」で、「86Mbps÷8bit=10.75MB/s」となるので、1秒当たり、10.75MBの転送速度となるらしいので、14TBを転送するのに必要な時間は、1TB = 1024GBで、1GB = 1024MBなので、

 ((1024 \times 1024 \times 14) \div 10.75) \div 3600 = 4077.79555556

4077.79555556時間だから、1日24時間働けますかで考えた場合、

 4077.79555556 \div 24 = 169.908148148

169.908148148 日かかりますと...

ほぼ半年ですな...

robocopyコマンドは、バックアップも、移行も、どっちにしろ、「移行元」から「移行先」へファイル群をコピーをするってことになるかと。(いろいろオプションを使えば変わってくるのかも知らんけど、よう分からん)

なので、バックアップ + 移行 でほぼ1年っすか...ファイルサーバの移行ってべらぼうに時間がかかるんですね。

あ、でも、土日とか祝日除くと、1ヵ月20日ぐらいの稼働で考えた時に、8か月+8か月で、16か月ってことは、1年4か月って...ちょっとした一大プロジェクトっぽいスケジュール感になっちゃうよね...

その前に、1日24時間働く前提がまずおかしいから、1日8時間労働として計算してみると、8か月×3+8か月×3 で、4年かかるらしい...オリンピックじゃないんだから...っていうぐらい絶望感しか無い...

あれかな、並列で実行とかすれば、もう少し短くなるのかな?

仮に、1TB × 14 って感じで14プロセスの並列処理と考えれば、1日24時間働けますか、で考えた場合、

 169.908148148 \div 14 = 12.1362962963

12日ぐらいで、1日8時間の労働だと、

 12.1362962963 \times 3 = 36.4088888889

だいたい、36日になるから、

36日+36日で、72日ということは、 1ヵ月20日の稼働で考えた場合、3か月半ぐらいになるのかな?

まぁ、実際には、こんな単純な計算になるわけもなく、並列処理になった時に、どれぐらいのパフォーマンスを維持できるかですよね...

だとしても、並列処理を使わなきゃ厳しいですよね...

悩ましいですな...

2020年6月8日(月)追記:↑ ここまで 

今回はこのへんで。