バックアップ

出典: 謎の百科事典もどき『エンペディア(Enpedia)』
記事をシェア:
X(旧Twitter)にシェアする
Threadsにシェアする
Facebookにシェアする
はてなブックマークにシェアする
LINEにシェアする
ナビゲーションに移動 検索に移動

バックアップ(backup)とは、

  1. コンピューターで破損時に備えた複製データ
  2. 支援をすること

本ページでは、1.について記載する。

概要[編集]

コンピュータ上の元のメモリーのデータの紛失、誤った編集・上書き保存、データの改ざん、災難、万が一の事故に備え、編集前のデータ、一度統一したデータが入っている元のメモリーを、別のメモリー、複数のメモリーに移転・コピーして、複製すること。

USBのデータをDVD-Rに一度書き込んだ後や、USBのデータを統一した後、以前と同じデータに、内容やデータの不足・失敗、編集、追加、訂正がありそうなときは、元のデータのUSBは絶対に編集しないで、別のUSBを用意し、元のUSBデータを、別のUSBに移転してバックアップし、どのUSBか確認しながら別のUSBで編集しなければならない。それは、過ちが起きるか起きないかどうかを予想・経験するためである。

データをバックアップするときに用意する必要なメモリーは、データ空のUSB、DVD-RW、DVD-R、Macのパソコンなど。DVD-Rは、最終バックアップが無難である。バックアップ用USBのデータ容量は、8GB以上(近年では、(8GBは無く、最低でも16GB以上)のものが必要となる。

編集前、一度統一した元のデータファイルが入っているUSBやDVD-Rなどのデータを、別のUSBにバックアップすることは、大切・重要なことである。編集前、一度統一した元のデータが入っているDVD-Rを、別のDVD-R[RW]にバックアップするには、先にデータ空のUSBにコピーが必須である。理由は、複数のDVD-R[RW]に書き込み・バックアップが楽にできるからである。バックアップしたDVD-R[RW]を保管するケースは、別の新しいDVD専用セミハードケースが必須で、バックアップ用DVDセミハードケースを作り、USBのデータは絶対に無期限に消さない。バックアップ済のUSBには、白のラベルに黒の油性ペンで「2回目コピー 編集禁止 バックアップ」と書いてUSBに貼るのが必須で、バックアップしたUSBを保管する袋は、バックアップ用USB専用の袋が必要である。理由は、バックアップ済の複数のDVD-R[RW]は、一部は、いつか他人に渡したり、予備品、家用、稀に事故が起きた場合などに使用される。家用は必須である。稀に事故が起きたときに備え、元のデータを復元・復旧できる。

バックアップしたDVD-R[RW]のうち、家用のものと、他人に渡すためのものとでは、それぞれ別のディスクセミハードケースを用意した方がよい。それは、データ用DVD-R[RW]は、中には、テレビ番組、地デジ放送番組をDVD機器に録画できる方式、テレビの画面をパソコンに録画した動画データファイルをDVDに書き込みできる方式のCPRMに対応しているものもあるからである。

上記の内容の取扱説明書・手順によるバックアップを知っている人であれば、将来、人生は、老化にブレーキが掛かり、年を取らない生き方、老化対策につながり、若々しさを保つことができ、万が一、年を取って老けても、困ることが少ない。

もし、万が一、以前と同じデータに統一の変更が浮かんで迷ってしまったときは、パソコンの操作はせずに、統一変更は絶対しないで、そのままDVD-R[RW]に書き込む。DVD-R[RW]に書き込み後でも、直接USBで統一の変更・改ざんすると、災難、無駄遣い、誤操作になるので禁止で、パソコンの内蔵ドキュメントで編集するか、に書くか、統一変更をやめるかどっちかである。統一変更すると、災難、操作の無限ループに陥ることがあり、成功できなくなるので、統一変更は絶対しない。

もし、仮に、USBデータを頻繁に編集し、操作が無限ループに陥りそうなときは、DVD-RWに書き込む。

様々なバックアップ[編集]

  • ファイル・フォルダコピーによるバックアップ
あるファイルを編集する前に、編集前の状態をコピーし、別のファイル名、別のメモリーで保存しておく。誤った編集内容を保存したり、違うファイルデータに置き換えてしまい、元に戻すのが難しい、或いは何らかのトラブルでファイルが破損し読み込めなくなってしまった際、先程別名で保存したファイルを改めて複製し、元の名前で保存し直せば元通り。
或いは、複数のファイルが収められているフォルダごと別の場所(別のフォルダ、外付けUSBディスク、或いはネットワークストレージ)へコピーしておき、同じく元に戻せるように備えておく。
自ら操作する必要があり、少々面倒な形式ではあるものの、難しい点はなく分かりやすい、追加費用もほとんどかからない、最も基本的なバックアップと言える。ファイル・フォルダバックアップを手軽に行うための支援ツールも無数にある。PCに結構詳しい人であれは、Windowsでは「Robocopy」コマンド、GNU/Linuxでは「rsync」コマンドを用いることで自由自在かつ安上がりに実現できるだろう。
  • 圧縮/展開ソフトを用いたアーカイブ化
複数のファイル・フォルダをまとめて1つのファイルにしたものをアーカイブ、または書庫ファイルと呼ぶ。アーカイブを作成するには「圧縮ソフト」、アーカイブを展開して中のファイルを利用できるようにするには「展開ソフト(解凍ソフト)」を用いる。
一般に、アーカイブ化されたされたファイル・フォルダはそのままでは閲覧・利用できず、展開する必要がある。その代わりに複数のファイルを単一のアーカイブファイルとして扱いやすくし、アーカイブをバックアップすることで、複数のファイル・フォルダをバックアップすることと同等となる。もっとも最近のOSはアーカイブをフォルダと同等に扱うことができる機能を備えるものがほとんど。
ごく一部の形式(tar形式など)を除き、ファイル・フォルダを「圧縮」することで、元々のファイル・フォルダのサイズ合計よりアーカイブファイルのサイズは小さくなる。これまでに様々な圧縮アルゴリズムが実用化されてきた(lzh形式、rar形式、gzip形式など)が、世界的ではzip形式がデファクトスタンダードとなっている。最近はzip形式との互換を持たせつつ圧縮率を高めた7z形式も広がりつつある。
  • フルバックアップ(イメージバックアップ)
ファイルやフォルダなどのデータだけでなく、OSのシステム領域や、インストールしたアプリケーション、デフォルトから変更した各種設定など、パソコンサーバー全体のバックアップを保存しておき、イメージファイルとしてまとめる(前述のアーカイブに近い)。
床に落としてしまった、落雷による過電流で内部回路が焼損してしまった、或いはコンピューターウイルスにやられてOSが起動できない等々の致命的な故障に見舞われても、事前に保存しておいたフルバックアップから部品交換修理後の機器へ復元(リカバリー)し、あたかも何事もなかったかのように復旧することが出来る、かも知れない。惨事復旧(Disaster Recovery)と表現したりする。
その仕組み上、例えば「CドライブのフルバックアップをCドライブ内の別のフォルダへ保存」は出来ない。外付けUSBディスクやDVD-RW、或いはNAS等ネットワークストレージ等、対象の記憶装置以外の記憶装置へ保存する必要がある(CドライブのフルバックアップをDドライブ内へ保存であれば可能)。
ファイル・フォルダのバックアップはある程度手軽にできる一方、OSやアプリを含むフルバックアップは技術的に難しく(Windowsシステム領域、およびユーザーから「隠されている」領域のバックアップは特殊な方法を用いる必要あり)、有償製品を利用するのが無難。「アクロニス」「パラゴン」、サーバー向けだと「アークサーブ」「ベリタス」などが結構実績あるメーカーか。特に「吹き飛んでしまうとそれこそ会社まで吹き飛んでしまうほど重要なサーバー」は必ず定期的にフルバックアップを保存すべし。
大半のバックアップ製品は2つのバックアップ方法に対応している。1つは、動作中のOSへバックアッププログラムをインストールし、自動的に動作するよう設定しておいて、動作中のOSをバックアップする方法(ホットバックアップ)。もう1つは、DVD-ROMや起動USBメモリ等で;機器を起動し、停止している状態のOSを手動バックアップする方法(コールドバックアップ)。
  • 増分バックアップ、差分バックアップ
ファイルをバックアップすると、ファイル容量が単純計算で2倍になる。塵も積もれば、空き容量を圧迫してしまう。
「同じファイル2つは、重複する部分も保存しなければならなくて、何だか無駄だなぁ」と考えた天才が、増分バックアップ、差分バックアップという概念を編み出した。
増分バックアップは、前回のバックアップから変化した部分(増分)のみを保存する。
例:9月1日にフルバックアップを保存する。9月2日は1日から増えた部分を保存。9月3日は2日からさらに増えた部分を保存。9月4日は3日からさらにさらに増えた部分を保存。以下繰り返し。
1回1回の増分バックアップの所要時間・容量は少な目だが、何らかのトラブルで9月2日の増分バックアップが吹き飛んだ場合、9月3日および9月4日の増分バックアップは使用不能になる。
差分バックアップは、ある地点でのフルバックアップから変化した部分(差分)のみを保存する。
例:9月1日にフルバックアップを保存する。9月2日は1日から変化した部分のみを保存。9月3日も1日から変化した部分のみを保存。9月4日も1日から変化した部分のみを保存。以下繰り返し。
9月2日の差分バックアップよりも、9月3日の差分バックアップよりも、9月4日の差分バックアップが所要時間・容量は増加する一方、9月2日の差分バックアップが吹き飛んでも9月3日の差分バックアップが吹き飛んでも、9月1日のフルバックアップと9月4日の差分バックアップの両方が無事である限りへっちゃら。
増分バックアップ・差分バックアップいずれも、その「起点」となるフルバックアップが必要となる。何らかのトラブルにより起点フルバックアップが吹き飛んでしまうと、それ以降に保存された増分・差分バックアップは役に立たなくなる。
同じ機器を繰り返しバックアップしたいという用途においては、フルバックアップの繰り返しよりも増分・差分バックアップのほうが容量節約になる。
有償バックアップ製品の大半は増分・差分いずれか、或いは両方に対応している(製品の方針により違いがある)。ある程度溜まった増分・差分を起点フルバックアップへ統合し、新たな起点フルバックアップとする「マージ(統合)」機能を備える製品も。
  • スナップショット
スナップショットは厳密にはバックアップと異なり、データそのものを保存するのではなく、あるパソコン・あるサーバーの前回からの「変化」を記録している。
差分バックアップと似ているが、バックアップは対象の記憶装置以外の記憶装置へ保存、スナップショットは対象の記憶装置内の別場所へ保存という考え方が近い。
差分バックアップから復元するには差分バックアップの起点となるフルバックアップが必要になるが、スナップショットにおける起点はスナップショット取得元の記憶装置そのもの。変化の記録を元に戻すことで、古いバージョンのファイルが復活する。
差分バックアップがフルバックアップ+差分バックアップの保存容量を必要とするのに対し、スナップショット保存に必要な保存容量は小さい。スナップショット取得に要する時間はせいぜい数分程度、大抵は数十秒で終わる。
一方、ディスクの故障などで元々のディスクが読み取れない場合、スナップショットは全く役に立たない。仕組みの都合上、バックアップと異なり別の外付けディスクやNAS等への保存はできない。
スナップショットとバックアップは異なる概念。あくまでバックアップを取ったうえで、追加でスナップショット機能を有効化するのが鉄則。
OSによっては、システムの状態のスナップショットを定期的・自動的に保存、不具合発生時に発生前の状態へ戻す機能を備えている。Windowsでは「復元ポイント」、Linux MintUbuntu等では「Timeshift」など。
  • ファイル履歴
ファイルの変更履歴を自動的に保存し、古いバージョンへ差し戻せる機能を持つアプリケーションやシステムが複数存在する(差分バックアップの応用と言える)。
Microsoft Excelは初期状態では履歴を保存しないものの、「変更履歴」機能を有効化することでxlsxファイル自体に過去の編集履歴を保存するようになる(履歴を有効にしていない状態と比べ、必然的にファイルサイズは増大する。また、最終版からは削除した情報も履歴に残っている場合があり、時としてセキュリティリスクと化す)。
OneDriveDropBoxなどクラウドストレージサービスの大半は、アップロードされたファイルの履歴が自動的に保存され、同じファイル名の古いバージョンを取り出すことができる。
ファイル履歴の話とは異なるが、ウィキペディアや我らがエンペディアなどMediaWikiは、各記事の履歴を保存し、必要に応じて過去の版へ戻す機能を備える。
規模の大きなアプリケーションの開発現場では、アプリケーションの元となるソースコードの変更履歴を保存しておき、誤った変更を取り消したりする等の仕組みを活用する(Git等のバージョン管理システム)
  • クラウドストレージ
上記ファイル履歴と話が被るが、DropBoxOneDriveGoogle DriveiCloudProton Drive等々、各社からクラウド上に構築されているファイル保存サービスが提供されている。
AndroidスマホへGoogleアカウントでサインインし「Google Driveへのバックアップ」を有効化すると、Wi-Fi接続時にスマホ内データがGoogle Driveへバックアップされる。機種変更した新しいスマホへ同じGoogleアカウントでサインインすると以前の機種のバックアップデータが新スマホへ復元され、以前とあまり変わらない使用感が戻ってくる。
  • 上記の自動バックアップはたしかに、便利ではあるが、アップロード前の暗号化なしで、Google Driveなどの安全ではないクラウドストレージ[注 1]に保存すべきではなく、自動バックアップも意図しないバックアップが行われるため、行うべきではない。[1][2][3][4][5][6][7][8][9][10][11][12][13][14][15][16][17][18][19]
  • Proton Driveは、保存したファイルがエンドツーエンド暗号化されるオープンソースのクラウドストレージである。アップロードする前の暗号化をせずに、安全に保存することができると思われる。

脚注[編集]

注釈[編集]

  1. Google Drive、DropBox、OneDrive、iCloudは安全ではない ちなみに、これらを運営している4企業はどれもPRISMに参加している。

出典[編集]

  1. enwp:Degoogle
    enwp:Privacy_concerns_with_Google
  2. enwp:PRISM
  3. https://policies.google.com/privacy
    https://policies.google.com/privacy/example/collect-information
  4. https://8ch.net/tech/chrome.html
    https://www.google.com/chrome/browser/privacy/index.html
    http://www.favbrowser.com/google-chrome-spyware-confirmed/
    https://jischinger.wordpress.com/2008/11/16/google-chrome-a-keylogger-privacy-concerns/
  5. https://campaignsoftheworld.com/news/the-dark-side-of-google/
    https://lifehacker.com/tech/google-is-a-bigger-privacy-nightmare-than-you-think
  6. https://www.huffingtonpost.com/nathan-newman/why-googles-spying-on-use_b_3530296.html
  7. https://www.gnu.org/proprietary/malware-google.html
    https://stallman.org/google.html
  8. 樽井秀人 (2021年3月23日). “Googleは個人情報を収集しすぎ! ~プライバシー重視の検索エンジンDuckDuckGoが批難”. forest.watch.impress.co.jp. https://forest.watch.impress.co.jp/docs/serial/yajiuma/1313713.html 
    “グーグル未承認広告メールはプライバシー侵害=個人情報監視団体”. jp.reuters.com. (2022年8月25日. https://jp.reuters.com/article/google-privacy-france-idJPKBN2PU1QD 
    GoogleMapのストリートビューはプライバシー侵害?削除依頼方法を解説”. ネット誹謗中傷弁護士相談Cafe (2022年6月17日).
  9. “<米国株情報>グーグル、プライバシー侵害訴訟で5000億円超の損害賠償の可能性”. kabushiki.jp. (2020年6月4日. https://kabushiki.jp/news/381296 
  10. Enrique Dans (2021年3月21日). “「これはシークレットではない」というグーグルの詭弁”. forbesjapan.com. https://forbesjapan.com/articles/detail/40434 
    Carrie Mihalcik (2020年6月4日). “グーグルに集団訴訟、「シークレットモード」でも情報収集”. japan.cnet.com. https://japan.cnet.com/article/35154770/ 
    “Google、シークレットモードでも情報収集をしていたとして提訴される”. iphone-mania.jp. (2020年6月5日. https://iphone-mania.jp/news-292770/ 
  11. https://gizmodo.com/apple-iphone-ipad-privacy-problems-data-gathering-1849855092
  12. https://www.theregister.com/2021/09/30/apple_google_privacy/
  13. https://www.gnu.org/proprietary/malware-apple.html.en
    https://stallman.org/apple.html
  14. https://spyware.neocities.org/articles/itunes
  15. https://web.archive.org/web/20180529202128/https://www.apple.com/legal/privacy/en-ww/
  16. https://www.apple.com/legal/privacy/en-ww/
  17. enwp:Criticism_of_Microsoft
  18. https://www.microsoft.com/ja-jp/privacy/privacystatement
  19. https://proton.me/blog/is-google-drive-secure
    https://proton.me/blog/apple-icloud-privacy
    https://proton.me/blog/apple-ad-company
    https://proton.me/blog/is-dropbox-secure

外部リンク[編集]