パスワードを忘れた？ アカウント作成
Close
178281 story
MacOSX

バックアップ用HDDに最適なファイルシステムは？ 107

ストーリー by soara
ファイルシステムとすると意外と難しい 部門より

あるAnonymous Coward 曰く、

本家/.で「外付けバックアップドライブに最適なファイルシステムは?」というストーリーが立っている。最近では大容量の HDDが安くなっているため、バックアップ用に外付けの HDDを使っている人も多いかとは思うが、FAT32では大容量のファイルを最大ファイルサイズの制限があるほか、ジャーナリング機構がないために不安が残る。NTFSはこれらの欠点が解消されているが、Windows以外の OSからは扱いにくい。ext3や ZFSなどは Linux/UNIXから利用するには良いが、Windowsや Macからでは操作しにくい。

単一の OS環境のみから利用するなら、それぞれの OSがデフォルトでサポートしているファイルシステムを利用するのが最適だろうが、複数の OSから利用される環境では、どのファイルシステムを使うのが（用途にもよるが）良いのだろうか？

ちなみに、本家/.では「安いマシン買って NASを作れ」とか、「NTFSは Macでも Linuxでも実用上は問題ないから NTFSで」とか、「FAT32で、4GB以上の動画は分割して保存して VLCで見ろ」とか、「ReiserFSだ。これはキラーだぜ」といった意見が出ている。

この議論は賞味期限が切れたので、アーカイブ化されています。 新たにコメントを付けることはできません。

バックアップ用HDDに最適なファイルシステムは？ More

  • raw device に直接 tar で書き込め
    多分、これが最も「常に七転八倒するが、長い期間どうにかなる」方式。
    Windows とかだと raw device へのアクセス方法を手に入れるのが最大の問題になるだろう。が、一旦そこをどうにかすれば、tar のソースコードは世の中に出回っているからどうにかこうにかなるだろう。
    最大の問題点は32bitにしか対応していない tar を使ってしまった場合かな。今つかうなら、最低限でも64bit対応でないと困るだろう。できれば 1024bit に拡張してから…
     
     
    FreeBSD+NFS+ZFSはよさそう
    ただし重複除去機能がつくのを待て。
    バックアップの場合、普段使いと違ってフラグメンテーションを起こしまくったファイルシステムでも大きな問題はない。むしろ大事なのは同じデータ部分を持ったファイルが幾つもあったりした場合に、こいつのせいでメディアがどんどん肥大化するのをどうやって止めるか。
    そこで重複除去機能。ZFSにこいつが入るのを待って、Raid1-6構成のメディア上にZFSを構築してそこにデータを保存しろ。そうすれば重複情報は削除しつつ、信頼性を確保出来る。
     
     

    「外に出せるものは外に出してしまい、まずバックアップしなくちゃいけないデータ量を減らせ」
    「Network File System (NFS じゃなくても AFS でも CoDa でも何でもいいが)で共有する事で、そもそもコピーを減らせ」
    「バックアップは複数取っておけ。できれば違うフォーマットで」
    という鉄則がまずあるかとは思いますが、それらを配慮した上でならばこんな感じじゃないかと。

    --
    fjの教祖様

    • ちょっとした疑問です、
      ZFS の新機能は Solaris に実装される方が早いのではないかと思うのですが(本家ですし)
      あえて FreeBSD の ZFS なのにはこだわりがあるのでしょうか？

      余ったパーツ(むしろ余らせた) + 奮発した HDD で
      FreeBSD で ZFS な NAS を作ってみたいなぁと思っているので気になるところです。

      ちなみに今は動画の類を NTFS な HDD に放り込んでいます。
      HDD をつないで再生できるメディアプレーヤなどでも NTFS 対応は結構あるようなので。
      PS3 は FAT32 だけですけど DLNA で再生するから問題なし。

      # 自分が FreeBSD なのは単純に Ubuntu と FreeBSD 位しか触ったことがないから……

      シェア
      親コメント

      • 余ったパーツでzfsを使用したFreeBSDサーバを構築する場合, 次の2点には注意しておいた方が良いです.

        • CPUは64bit対応(AMDのOpteron/Athlon64以降かintelのCore2以降)
        • メモリは最低限1GB. できたら2GB以上

        32bit対応のみのCPUでも使えないことは無いのですが, amd64版だとチューニングパラメータをいちいちいじらなくてもよろしくやってくれるので, かなり楽ができます. またzfsを使用するとカーネルがキャッシュやらなんやらで512MB以上消費する場合があるので, メモリ1GBぐらいが最低限のラインになります.(カーネルに割り当てたメモリが足らなくなるとpanicで落ちます)

        このあたりは細かくパラメータを調整したり, あるいは最近のzfs v13では改善されているかもしれませんが, 安全パイを取るならamd64で4GB以上(最近ではそれほどきつい条件ではなくなりましたから)ってのが目安でしょう. そういう意味ではzfsに限ればSolarisの方が安全・確実と言えるかもしれません.

        シェア
        親コメント

      • ZFS の新機能は Solaris に実装される方が早いのではないかと思うのですが(本家ですし)
        あえて FreeBSD の ZFS なのにはこだわりがあるのでしょうか？

        素晴らしい質問です。「なぜ一番最初にリリースされるものを使わないのか」

        .

        理由は「バグを回避するため」。

        ZFSに限りませんが、この手のプログラム、バグは2種類あります。

        1) 機能を定義し、最初の実装を行った段階で入り込んだバグ。経験不足(そりゃ、初めてですから)に起因する
              考慮不足などのせいで、うまく行くと思っていたことがうまくいかなくてギャーー 的な問題
        2) 1を一通りクリアした後、2つ目のOSに移植する際に、ベースのOSの性質が違ったり、
            インターフェースを合わせるために無理をしたときに出てくるバグ。

        2 の場合、ストレージレベルでのフォーマット間違いとか、そう言うのは余り出てきません。マウントできないとか、バイナリレベルで読んでみたら Solaris 版と出て着るものがぜんぜん違うわこれ、とか、結構初期の段階で発見、fix できる。本質的にうまく行くのは 1 を通過した後なので大丈夫。

        なので、Solaris ZFSではなく、FreeBSD ZFS であればかなり信頼できるものが最初から出てくるに違いない、とそういうわけです。

        .

        この手の情報は、man page を良く読んでいると判ることがあります。
        某OSに ext2 が移植された際、bugs の項にはこう書かれていました。
        「オリジナルと異なり、同期書き込みでは、ちゃんと同期的に書き込んでしまう。」

        このように、オリジナル側が「無い」と主張しているバグについて、コメントが皮肉っぽく書かれたらもう大丈夫。

        --
        fjの教祖様
        シェア
        親コメント

        • Re:どういうアクセス方式でつかうのか問わないなら… (スコア:1, 興味深い)

          by Anonymous Coward on 2009年12月27日 10時05分 (#1694822)

          >理由は「バグを回避するため」。
          ...
          >なので、Solaris ZFSではなく、FreeBSD ZFS であればかなり信頼できるものが最初から出てくるに違いない、とそういうわけです。

          portingのバグは考えないの? 現にFreeBSDでzfsが導入されてからずっと、結構不安定な状態が続いていたよね。
          新しいバージョンの最初を避けるというのであれば、zfsはSXCE→OpenSolaris→Solaris10の順番で流れてくるから、Solaris10を使うってのが安心だと思うけど。

          シェア
          親コメント

          • portingのバグは考えないの?

            porting のバグは 2 の一部として考慮してありますが。
            重複除去は、基本的にファイルシステムの上で動作するものです。なので 1 と 2 では、 1 の比重が圧倒的に高い。

            現にFreeBSDでzfsが導入されてからずっと、結構不安定な状態が続いていたよね。

            続いてますね。だからこそ FreeBSD にポートされるのを待つべきなんです。

            .

            すでに述べたようにバグには2種類あります。
            1つ目はそもそもの実装案に内在する「思慮不足」起因のバグ。

            2つ目は「純粋に実装起因の」バグ。porting などで特に露呈しますが、ようするに外部とのインターフェース、外部へのインターフェースの不整合に起因するバグです。

            「ZFS を実装/移植する」事そのものは、実は 1 のバグと 2 のバグが同じぐらい存在します。というか、同じ程度にしか存在しません。ファイルシステムそのものは世の中に沢山存在します。実装はいくつもオープンになっており、論文も沢山出ている。このため、1 の部分で失敗する事は少ない。 2 の部分で「あ…特定のOSへの実装に偏りすぎた」と言うのが露呈する事が多い。

            それが FreeBSD に移植する際に起こっている事です。もっと言えば、FreeBSD に移植する際に発見された問題のいくつかは、本家本元がインターフェースに対して立てていた大前提が間違っていたと言うことで、他のOSでも同様の問題となって発現するでしょう。異なるOSのメンテナは異なる視点からプログラムの動作をチェックするので、「安定しない」のは当たり前です。

            .

            しかし「ZFS に重複除去機能を追加する」場合は、1 のバグが殆どで、2のバグは殆ど出てこないはずです。重複除去機能そのものが可能なのは、すでに商用システムにそのようなものが存在することから自明です。しかし、これを実装した際にどのような問題が起こり得るのかは、従来のファイルシステム実装自身程判っているわけじゃない。つまり 1 が発生する確率は、ファイルシステムそのものを実装する際よりも、高い。

            これに対して、2、つまり重複除去機能が完成した場合にこれを「FreeBSD 上で動作している ZFS に追加する」場合に生じる porting bug は圧倒的に少なくなる。なぜなら、重複除去機能は ZFS の「内部機能」だから。重複除去のために追加されなくてはいけない OS 外部とのインターフェースは遥かに少なくて済むはずです。と言うことは 2 にともなうバグは圧倒的に少なくて済む。

            しかるに。1のバグがまだ不安な状態で別のOSのメンテナが port を始めることはありません。無駄足に終わる可能性が非常に高いからです。

            .

            この二つを混同して評価するのは、プログラミングにおいてバグがどういう具合に発生するのか、その本質を理解していない証拠と言えます。

            --
            fjの教祖様
            シェア
            親コメント

  • いや，だから (スコア:2, おもしろおかしい)

    by ksyuu (4917) on 2009年12月26日 15時40分 (#1694632) 日記

    そんなことで悩むくらいならいっその事最強の紙に…（略

    • Re:いや，だから (スコア:1)

      by kujira090 (16707) on 2009年12月29日 3時28分 (#1695404) 日記

      肌色動画を紙に記録してどうするんだよ。
      石に記録したらミロのヴィーナスになるのか？

      ＃消えたら消えたで悲しいが、他人に見せられないデータは、墓場に行く前には消えてほしいと思う、HDDを大掃除中な今日この頃

      --
      ＃壮大なストーリ。空転するアイディア。
      シェア
      親コメント

  • NTT作 NILFS (スコア:2, 参考になる)

    by reininn (35924) on 2009年12月26日 15時49分 (#1694635)
    私は、NTT作 NILFS を使っています。

  • バックアップソフトのおすすめは？ (スコア:1, 興味深い)

    by Anonymous Coward on 2009年12月26日 12時07分 (#1694548)
    OS別にしないと混乱するか。

  • で答えは？ (スコア:1, 興味深い)

    by Anonymous Coward on 2009年12月26日 12時28分 (#1694558)

    ＞「安いマシン買って NASを作れ」
    その中のフォーマットは何なんだよー

    Linuxはext3で使ってるけど
    extも2と3でどれほど安定性が違うのか理解してないし
    (適当に3の方が新しそうだから使ってる)

    WindowsはNTFSだけど、OSによって微妙にバージョン違うし
    (XpでフォーマットしたけどWin7でアクセスできてるからいいか。とか)

    まぁ自分的にはこの２択だけど
    じゃあこの２つでどっちが良いのか？と聞かれると困る。

  • raw デバイス+tarアーカイブでテープドライブみたいに使うとかどうだろうか?

    大容量でもバックアップだけなら、ランダムアクセス性能は考えなくてもいいかもしれないし(違

    # 正直、極小だけどメモリはある装置にドライブを繋いでZFSとかでネットワークFS(NFS/SMB/iSCSI)を公開するのが確実だろうなぁ、とか思う

    --
    M-FalconSky (暑いか寒い)

  • FSなど些末な事 (スコア:1)

    by Dobon (7495) on 2009年12月26日 13時54分 (#1694601) 日記
    パーティションを丸ごとコピーしてしまえばファイルシステムなど些末な事です。
    ファイル単位でちまちまバックアップするなら、どのファイルシステムでも大差はないでしょう。
    --
    notice : I ignore an anonymous contribution.

  • 臨機応変 (スコア:1)

    by duenmynoth (34577) on 2009年12月26日 14時30分 (#1694613) 日記
    何をどのくらいバックアップするかで最適解が違ってくるかと

    ＃画像や動画を保存しとくならあれこれ考えず素直にNTFSでいいと思いますが

  • 現実解 (スコア:1)

    by Dobon (7495) on 2009年12月26日 14時55分 (#1694618) 日記
    複数のOS、外付けドライブ、初心者でも手順書があれば操作可能という条件ならば、FAT32でしょう。

    # "リカバリレコード付で分割セーブ可能なバックアップソフト"の選定が問題になりますが……
    --
    notice : I ignore an anonymous contribution.

    • Re:現実解 (スコア:2, おもしろおかしい)

      by Anonymous Coward on 2009年12月26日 17時33分 (#1694660)
      急いで口で吸えばいいんですね

      # 経験者なら分かってもらえる
      シェア
      親コメント

    • Re:現実解 (スコア:1, 興味深い)

      by Anonymous Coward on 2009年12月26日 19時06分 (#1694693)

      その条件だとバックアップソフトではありませんが、WinRARしか考えられませんね。
      アーカイブ属性を見て立ってないと除外とか圧縮後ビットクリアとかかなり高機能です。
      7-zipはリカバリレコードないのが無念。

      寡聞にしてリカバリレコードを持ちつつある程度広まっているアーカイバといえば
      WinRARしか知らないのですが、他になにかありませんか？

      シェア
      親コメント

      • Re:現実解 (スコア:1)

        by Dobon (7495) on 2009年12月26日 19時38分 (#1694699) 日記
        DGCAというのがありますが、Windows専用です。

        > WinRARしか考えられませんね。
        　やはり、現実解はrarですか。

        rarならば、win,poketpc,linux,bsd,MacOSX,DOSで使えますが、
        Windows系とMac系以外はコマンドライン操作になってしまいます。

        linuxやbsdを使う人ならコマンドラインでも問題ないからいいのかな？
        --
        notice : I ignore an anonymous contribution.
        シェア
        親コメント

  • NTFSからext3へコピーしようとしたらできないファイルがあった。
    ファイル名255バイトまでとかやめてほしい。

  • バックアップとは？ (スコア:1)

    by saitoh (10803) on 2009年12月28日 10時23分 (#1694974)
    何でバックアップ先用ファイルシステムにジャーナリング機能がないことが欠点になるんだ？と、しばらく悩んでしまった

    どうも、バックアップソフトを使って巨大なファイルをひとつ書き込むと思っているのは年寄りで、 「ファイルシステムの個々のファイルをそのまま個別のままにコピーすることがバックアップだ」ってのがもう主流なのかなぁ。

    • そのバックアップは、そのソフトがないと展開できない。複数OSから利用可能ってのは、特定アプリに依存しないってのも含むわけ。
      そういうフリーダムなバックアップは、セキュリティ上むしろどうよというのはおいとく。
      シェア
      親コメント

    • Re:バックアップとは？ (スコア:1)

      by saitoh (10803) on 2009年12月28日 13時53分 (#1695069)
      なるほどね。 ただ、1ファイルをバックアップしてバックアップ先に1ファイルを作る方式はどうしても速度が出ない（バックアップの所要時間が長くなる）。上のコメントをず～～と読んだけど所要時間を気にしている人は居ないみたい。 個人向けだとそんなものか、と納得。
      シェア
      親コメント
typodupeerror

あと、僕は馬鹿なことをするのは嫌いですよ (わざとやるとき以外は)。-- Larry Wall