Linux-admin-backup-and-recovery
Linux Admin-バックアップと復元
標準バックアップ計画を展開するためのCentOS固有の方法を検討する前に、まず標準レベルのバックアップポリシーの一般的な考慮事項について説明しましょう。 最初に慣れたいのは、* 3-2-1バックアップルール*です。
3-2-1バックアップ戦略
業界全体で、3-2-1バックアップモデルという用語をよく耳にします。 これは、バックアップ計画を実施する際の非常に優れたアプローチです。 3-2-1は次のように定義されます。 3 データのコピー。たとえば、作業コピーがある場合があります。 rsyncを使用した冗長性のために設計されたCentOSサーバーに置かれたコピー。ローテーションされたオフサイトUSBバックアップは、バックアップサーバー上のデータから作成されます。 2 さまざまなバックアップメディア。 この場合、実際には3つの異なるバックアップメディアがあります。ラップトップまたはワークステーションのSSD上の作業コピー、RADI6アレイ上のCentOSサーバーデータ、およびUSBドライブに配置されたオフサイトバックアップです。 1 オフサイトのデータのコピー。 USBドライブを毎晩オフサイトで回転させています。 別の最新のアプローチは、クラウドバックアッププロバイダーです。
システム回復
_ベアメタルリストアプラン_は、CentOS管理者がすべてのデータを無傷で重要なシステムをオンラインにするために設計した単純なプランです。 100％のシステム障害と過去のすべてのシステムハードウェアの損失を想定した場合、管理者は、ユーザーデータを損なわずにダウンタイムを最小限に抑えてアップタイムを達成する計画を立てる必要があります。 Linuxで使用されるモノリシックカーネルは、システムイメージを使用したベアメタルリストアをWindowsよりもはるかに簡単にします。 Windowsがマイクロカーネルアーキテクチャを使用している場合。
通常、完全なデータの復元とベアメタルの復元は、主要な運用サーバーの稼働中の構成された運用ディスクイメージ、3-2-1ルールに準拠したユーザーデータの冗長バックアップなどの方法の組み合わせによって実現されます。 信頼できる会社の従業員へのアクセスが制限された、安全で耐火性の金庫に保存される可能性のある機密ファイルもあります。
ネイティブCentOSツールを使用したマルチフェーズ_ベアメタルリストア_および_データリカバリプラン_は、
- dd構成済みサーバーの実動ディスクイメージを作成および復元する
- すべてのユーザーデータの増分バックアップを作成するrsync
- tarおよびgzipを使用して、ファイルの暗号化されたバックアップを管理者からのパスワードとメモとともに保存します。 通常、これはUSBドライブに配置し、暗号化して、シニアマネージャーがアクセスできる金庫にロックすることができます。 また、これにより、現在の管理者が宝くじに当選し、日当たりの良い島に姿を消した場合に、他の誰かが重要なセキュリティ資格情報を知ることができます。
システムがハードウェア障害または災害のためにクラッシュした場合、以下は操作を復元するさまざまなフェーズになります-
- 構成されたベアメタルイメージを使用して動作するサーバーを構築する
- バックアップから作業サーバーにデータを復元する
- 最初の2つの操作を実行するために必要な資格情報に物理的にアクセスできる
ファイルレベルのバックアップにrsyncを使用する
_rsync_は、ファイルのディレクトリをローカルまたは別のサーバーに同期するための優れたユーティリティです。 _rsync_はシステム管理者によって長年使用されてきたため、データのバックアップを目的として非常に洗練されています。 著者の意見では、_sync_の最も優れた機能の1つは、コマンドラインからスクリプトを作成できることです。
このチュートリアルでは、さまざまな方法でrsyncについて説明します-
いくつかの一般的なオプションについて調べて話し合う
ローカルバックアップを作成する
SSH経由でリモートバックアップを作成する
ローカルバックアップを復元する
*rsync* の目的は_Remote Sync_であり、強力かつ柔軟に使用できます。
以下は、sshを介した基本的な_rsync_リモートバックアップです-
MiNi:~ rdc$ rsync -aAvz --progress ./Desktop/ImportantStuff/
[email protected]:home/rdc/Documents/RemoteStuff/
[email protected]'s password:
sending incremental file list
6,148 100% 0.00kB/s 0:00:00 (xfr#1, to-chk=23/25)
2017-02-14 16_26_47-002 - Veeam_Architecture001.png
33,144 100% 31.61MB/s 0:00:00 (xfr#2, to-chk=22/25)
A Guide to the WordPress REST API | Toptal.pdf
892,406 100% 25.03MB/s 0:00:00 (xfr#3, to-chk=21/25)
Rick Cardon Technologies, LLC..webloc
77 100% 2.21kB/s 0:00:00 (xfr#4, to-chk=20/25)
backbox-4.5.1-i386.iso
43,188,224 1% 4.26MB/s 0:08:29
sent 2,318,683,608 bytes received 446 bytes 7,302,941.90 bytes/sec
total size is 2,327,091,863 speedup is 1.00
MiNi:~ rdc$次の同期により、約2.3GBのデータがLAN経由で送信されました。 rsyncの利点は、ファイルごとにブロックレベルで段階的に機能することです。 つまり、1MBのテキストファイルで2文字だけを変更すると、次の同期で1つまたは2つのブロックのみがLANを介して転送されます。
さらに、CPU使用率を下げるために使用するネットワーク帯域幅を増やすために、インクリメンタル機能を無効にすることができます。 これは、1Gb専用のバックアップランで10分ごとに複数の10MBデータベースファイルを絶えずコピーする場合に推奨されます。 理由は次のとおりです。これらは常に変化し、10分ごとに徐々に送信され、リモートCPUの負荷に負担をかける可能性があります。 合計転送負荷は5分を超えないため、データベースファイル全体を同期することもできます。
以下は、_rsync_を使用した最も一般的なスイッチです-
rsync syntax:
rsync [options] [local path] [[remote host:remote path] or [target path| Switch | Action |
|---|---|
| -a | Archive mode and assumes -r, -p, -t, -g, -l |
| -d | Sync only directory tree, no files |
| -r | Recursive into directory |
| -l | Copy symlinks as symlinks |
| -p | Preserve permissions |
| -g | Preserve group |
| -v | Verbose output |
| -z | Compress over network link |
| -X | Preserve extended attributes |
| -A | Preserve ACLs |
| -t | Preserve timestamps |
| -W | Transfer whole file, not incremental blocks |
| -u | Do not overwrite files on target |
| --progress | Show transfer progress |
| --delete | Delete older files on target |
| --max-size = XXX | Max file size to sync |
rsyncを使用する場合
_rsync_の個人的な好みは、ソースホストからターゲットホストにファイルをバックアップするときです。 たとえば、データ復旧のためのすべてのホームディレクトリ、または災害復旧のためのオフサイトおよびクラウドへのアクセス。
rsyncを使用したローカルバックアップ
あるホストから別のホストにファイルを転送する方法はすでに見ました。 同じ方法を使用して、ディレクトリとファイルをローカルで同期できます。
rootユーザーのディレクトリで_/etc/_の手動増分バックアップを作成しましょう。
最初に、同期バックアップ用に〜/rootからディレクトリを作成する必要があります-
[root@localhost rdc]# mkdir/root/etc_baks次に、十分な空きディスク領域があることを確認します。
[root@localhost rdc]# du -h --summarize/etc/
49M /etc/
[root@localhost rdc]# df -h
Filesystem Size Used Avail Use% Mounted on
/dev/mapper/cl-root 43G 15G 28G 35% //etc/ディレクトリ全体を同期するのに適しています-
rsync -aAvr/etc//root/etc_baks/同期された/etc/ディレクトリ-
[root@localhost etc_baks]# ls -l ./
total 1436
drwxr-xr-x. 3 root root 101 Feb 1 19:40 abrt
-rw-r--r--. 1 root root 16 Feb 1 19:51 adjtime
-rw-r--r--. 1 root root 1518 Jun 7 2013 aliases
-rw-r--r--. 1 root root 12288 Feb 27 19:06 aliases.db
drwxr-xr-x. 2 root root 51 Feb 1 19:41 alsa
drwxr-xr-x. 2 root root 4096 Feb 27 17:11 alternatives
-rw-------. 1 root root 541 Mar 31 2016 anacrontab
-rw-r--r--. 1 root root 55 Nov 4 12:29 asound.conf
-rw-r--r--. 1 root root 1 Nov 5 14:16 at.deny
drwxr-xr-x. 2 root root 32 Feb 1 19:40 at-spi2
--{ condensed output }--今、インクリメンタルrsyncをやってみましょう-
[root@localhost etc_baks]# rsync -aAvr --progress /etc//root/etc_baks/
sending incremental file list
test_incremental.txt
0 100% 0.00kB/s 0:00:00 (xfer#1, to-check=1145/1282)
sent 204620 bytes received 2321 bytes 413882.00 bytes/sec
total size is 80245040 speedup is 387.77
[root@localhost etc_baks]#_test_incremental.txt_ファイルのみがコピーされました。
rsyncを使用したリモート差分バックアップ
バックアップ計画が展開されたサーバーに、最初のrsync完全バックアップを実行しましょう。 この例では、実際にMac OS Xワークステーション上のフォルダーをCentOSサーバーにバックアップしています。 _rsync_のもう1つの優れた側面は、rsyncが移植されたどのプラットフォームでも使用できることです。
MiNi:~ rdc$ rsync -aAvz Desktop/ImportanStuff/
[email protected]:Documents/RemoteStuff
[email protected]'s password:
sending incremental file list
./
A Guide to the WordPress REST API | Toptal.pdf
Rick Cardon Tech LLC.webloc
VeeamDiagram.png
backbox-4.5.1-i386.iso
dhcp_admin_script_update.py
DDWRT/
DDWRT/.DS_Store
DDWRT/ddwrt-linksys-wrt1200acv2-webflash.bin
DDWRT/ddwrt_mod_notes.docx
DDWRT/factory-to-ddwrt.bin
open_ldap_config_notes/
open_ldap_config_notes/ldap_directory_a.png
open_ldap_config_notes/open_ldap_notes.txt
perl_scripts/
perl_scripts/mysnmp.pl
php_scripts/
php_scripts/chunked.php
php_scripts/gettingURL.php
sent 2,318,281,023 bytes received 336 bytes 9,720,257.27 bytes/sec
total size is 2,326,636,892 speedup is 1.00
MiNi:~ rdc$これで、ワークステーションのフォルダを、オフサイトに保存されたディザスタリカバリメディアが回転するRAID6ボリュームを実行しているサーバーにバックアップしました。 rsyncを使用すると、標準の3-2-1バックアップが得られ、高価な冗長ディスクアレイとローテーションされた差分バックアップを備えたサーバーが1台だけになりました。
_test_file.txt_という名前の新しいファイルが1つ追加された後、rsyncを使用して同じフォルダーの別のバックアップを実行しましょう。
MiNi:~ rdc$ rsync -aAvz Desktop/ImportanStuff/
[email protected]:Documents/RemoteStuff
[email protected]'s password:
sending incremental file list
./
test_file.txt
sent 814 bytes received 61 bytes 134.62 bytes/sec
total size is 2,326,636,910 speedup is 2,659,013.61
MiNi:~ rdc$ご覧のとおり、_rsync_を介して新しいファイルのみがサーバーに配信されました。 差分比較はファイルごとに行われました。
注意すべき点がいくつかあります：これは、変更された唯一のファイルであるため、新しいファイルtest_file.txtのみをコピーします。 rsyncはsshを使用します。 どちらのマシンでもルートアカウントを使用する必要はありませんでした。
シンプルで強力かつ効果的な_rsync_は、フォルダ全体およびディレクトリ構造のバックアップに最適です。 ただし、_rsync_自体はプロセスを自動化しません。 ここで、ツールボックスを掘り下げて、仕事に最適な、小さくてシンプルなツールを見つける必要があります。
_cronjobs_を使用してrsyncバックアップを自動化するには、SSHユーザーを認証用のSSHキーを使用してセットアップすることが不可欠です。 これとcronjobsの組み合わせにより、rsyncを一定の間隔で自動的に実行できます。
ブロックごとのベアメタルリカバリイメージにDDを使用する
DDは、GNU Utilitiesを満たすLinuxカーネルのkernel明期から存在するLinuxユーティリティです。
_dd_は、最も簡単な用語で、選択したディスク領域のイメージをコピーします。 次に、物理ディスクの選択したブロックをコピーする機能を提供します。 したがって、バックアップがない限り、ddがディスクに書き込むと、すべてのブロックが置き換えられます。 以前のデータの損失は、高レベルのプロレベルのデータリカバリでさえ、リカバリ機能を超えています。
_dd_でブート可能なシステムイメージを作成するためのプロセス全体は次のとおりです-
- ブート可能なLinuxディストリビューションでCentOSサーバーからブートします
- イメージングするブート可能ディスクの指定を見つけます
- リカバリイメージを保存する場所を決定する
- ディスクで使用されているブロックサイズを見つける
- ddイメージ操作を開始します
このチュートリアルでは、時間と簡略化のために、CentOS仮想マシンからマスターブートレコードのISOイメージを作成します。 その後、この画像をオフサイトに保存します。 MBRが破損して復元する必要がある場合、同じプロセスをブート可能なディスクまたはパーティション全体に適用できます。 ただし、必要な時間とディスク容量は、このチュートリアルでは実際より少し過剰になります。
CentOS管理者は、テスト環境で完全に起動可能なディスク/パーティションの復元に習熟し、ベアメタル復元を実行することをお勧めします。 マネージャーと数十人のエンドユーザーがダウンタイムを数えている現実の状況で、最終的に練習を完了する必要がある場合、これは多くのプレッシャーを取り除きます。 そのような場合、物事を10分間理解することは永遠のように思え、汗をかきます。
注意-ddを使用するときは、ソースボリュームとターゲットボリュームを混同しないようにしてください。 バックアップ場所をブートドライブにコピーすることにより、データとブート可能なサーバーを破壊できます。 または、非常に低いレベルのデータをDDでコピーすることにより、データを永久に破壊する可能性があります。
以下は、_dd_の一般的なコマンドラインスイッチとパラメーターです-
| Switch | Action |
|---|---|
| if= | In file or source to be copied |
| of= | Out file or the copy of the in file |
| bs | Set both input and output block size |
| obs | Set output file block size |
| ibs | Set input file block size |
| count | Set the number of blocks to copy |
| conv | Extra options to add for imaging |
| Noerror | Do not stop processing an error |
| sync | Pads unfitted input blocks in the event of error or misalignment |
ブロックサイズに関する注意-ddのデフォルトのブロックサイズは512バイトです。 これは、低密度のハードディスクドライブの標準ブロックサイズでした。 今日の高密度HDDは4096バイト（4kB）のブロックサイズに増加し、1TB以上のディスクに対応しています。 したがって、新しい大容量のハードディスクでddを使用する前に、ディスクブロックサイズを確認する必要があります。
このチュートリアルでは、_dd_を使用して運用サーバーで作業する代わりに、VMWareで実行されているCentOSインストールを使用します。 また、起動可能なUSBスティックを使用する代わりに、起動可能なLinux ISOイメージを起動するようにVMWareを構成します。
まず、_CentOS Gnome ISO_というタイトルのCentOSイメージをダウンロードする必要があります。 これはほぼ3GBであり、ブート可能なUSBサムドライブを作成し、トラブルシューティングおよびベアメタルイメージのために仮想サーバーインストールを起動するために、常にコピーを保持することをお勧めします。
他の起動可能なLinuxディストリビューションも同様に機能します。 Linux Mintは、優れたハードウェアサポートとメンテナンス用の洗練されたGUIディスクツールを備えているため、ブート可能なISOに使用できます。
CentOS GNOME Liveブータブルイメージは、http：//buildlogs.centos.org/rolling/7/isos/x86_64/CentOS-7-x86_64-LiveGNOME.isoからダウンロードできます。
Linuxブート可能イメージからブートするようにVMWare Workstationインストールを構成しましょう。 手順は、OS X上のVMWare用です。 ただし、Linux、Windows、さらにはVirtual Box上のVMWare Workstationでも同様です。
注-Virtual BoxやVMWare Workstationなどの仮想デスクトップソリューションを使用すると、CentOS管理タスクを学習するためのラボシナリオを設定するのに最適な方法です。 複数のCentOSインストールをインストールする機能を提供します。実際にはハードウェア構成がなく、管理に集中できます。また、変更を行う前にサーバーの状態を保存することもできます。
まず、仮想CD-ROMを構成し、仮想CentOSサーバーのインストールの代わりにISOイメージをブートに添付します-
今、起動ディスクを設定します-
これで、起動時に仮想マシンがCentOSのブート可能なISOイメージから起動し、以前に構成された仮想CentOSサーバー上のファイルにアクセスできるようになります。
ディスクをチェックして、MBRのコピー元を確認します（圧縮された出力は次のとおりです）。
MiNt ~ # fdisk -l
Disk/dev/sda: 60 GiB, 21474836480 bytes, 41943040 sectors
Units: sectors of 1 *512 = 512 bytes
Sector size (logical/physical): 512 bytes/512 bytes
I/O size (minimum/optimal): 512 bytes/512 bytes
Disk/dev/sdb: 20 GiB, 21474836480 bytes, 41943040 sectors
Units: sectors of 1* 512 = 512 bytes
Sector size (logical/physical): 512 bytes/512 bytes
I/O size (minimum/optimal): 512 bytes/512 bytes_sda_と_sdb_の両方の物理ディスクを見つけました。 各ブロックのサイズは512バイトです。 そのため、ここで_dd_コマンドを実行して、SDA1上のMBRの最初の512バイトをコピーします。
これを行うための最良の方法は-
[root@mint rdc]# dd if=/dev/sda bs=512 count=1 | gzip -c >
/mnt/sdb/images/mbr.iso.gz
1+0 records in
1+0 records out
512 bytes copied, 0.000171388 s, 3.0 MB/s
[root@mint rdc]# ls/mnt/sdb/
mbr-iso.gz
[root@mint rdc]#このように、マスターブートレコードの完全なイメージがあります。 ブートドライブのイメージを作成するのに十分なスペースがあれば、完全なシステムブートイメージを簡単に作成できます-
dd if=/dev/INPUT/DEVICE-NAME-HERE conv=sync,noerror bs=4K | gzip -c >
/mnt/sdb/boot-server-centos-image.iso.gz_conv = sync_は、物理メディアのバイトを揃える必要がある場合に使用されます。 この場合、正確な4Kアライメントが読み取れないと、ddがエラーになる場合があります（たとえば… 3Kだけのファイルですが、ディスク上で少なくとも4Kブロックを1つ取得する必要があります。 または、単に読み取りエラーが発生し、ddがファイルを読み取ることができません。） したがって、_conv = sync、noerror_を指定した_dd_は、3Kに、些細だが有用なデータを4Kブロックのアライメントで物理メディアにパディングします。 大規模な操作を終了させる可能性のあるエラーは表示されません。
ディスクからのデータを操作するときは、常に_conv = sync、noerror_パラメーターを含める必要があります。
これは、ディスクがTCPデータのようなストリームではないためです。 それらは、特定のサイズに揃えられたブロックで構成されています。 たとえば、512バイトのブロックがある場合、わずか300バイトのファイルには512バイトのディスクスペースが必要です（パーミッションやその他のファイルシステム情報などのiノード情報用に2ブロックが必要な場合があります）。
セキュアストレージにgzipとtarを使用する
gzipとtarは、CentOS管理者が使い慣れた2つのユーティリティです。 これらは、単にアーカイブを解凍するだけでなく、はるかに多くの目的で使用されます。
CentOS LinuxでGnu Tarを使用する
Tarは、Windowsの_winrar_に似たアーカイブユーティリティです。 その名前_Tape Archive_は_tar_と略され、ユーティリティをほとんどまとめています。 _tar_はファイルを取得し、論理的な利便性のためにアーカイブに配置します。 したがって、/etcに保存されている多数のファイルの代わりに。 バックアップとストレージの利便性のために、それらをアーカイブに「tar」するだけで済みます。
_tar_は、長年にわたってUnixおよびLinuxでアーカイブファイルを保存するための標準でした。 したがって、_gzip_または_bzip_とともにtarを使用することは、各システムのアーカイブのベストプラクティスと見なされます。
以下は、tarで使用される一般的なコマンドラインスイッチとオプションのリストです-
| Switch | Action |
|---|---|
| -c | Creates a new .tar archive |
| -C | Extracts to a different directory |
| -j | Uses bzip2 compression |
| -z | Uses gzip compression |
| -v | Verbose show archiving progress |
| -t | Lists archive contents |
| -f | File name of the archive |
| -x | Extracts tar archive |
以下は、_tar_アーカイブを作成するための基本的な構文です。
tar -cvf [tar archive name]- tarを使用した圧縮メカニズムに関する注意*-tarを使用する場合は、gzipとbzip2の2つの一般的な圧縮スキームのいずれかに固執することをお勧めします。 gzipファイルはより少ないCPUリソースを消費しますが、通常はサイズが大きくなります。 bzip2は圧縮に時間がかかりますが、より多くのCPUリソースを使用します。ただし、最終ファイルサイズは小さくなります。
ファイル圧縮を使用するときは、標準のファイル拡張子を常に使用して、アーカイブを抽出するために必要な圧縮スキームを（試行錯誤による推測とは対照的に）自分自身を含む全員に知らせたいと思います。
| bzip2 | .tbz |
| bzip2 | .tar.tbz |
| bzip2 | .tb2 |
| gzip | .tar.gz |
| gzip | .tgz |
Windowsボックスで、またはWindowsで使用するためにアーカイブを抽出する必要がある場合は、ほとんどの3文字の単一拡張子がWindowsとWindowsのみの管理者を混乱させるため、。tar.tbz_または.tar.gz_を使用することをお勧めします（ただし、それは時々望ましい結果です）
Macワークステーションからコピーしたリモートバックアップから_gzipped_ tarアーカイブを作成しましょう-
[rdc@mint Documents]$ tar -cvz -f RemoteStuff.tgz ./RemoteStuff/
./RemoteStuff/
./RemoteStuff/.DS_Store
./RemoteStuff/DDWRT/
./RemoteStuff/DDWRT/.DS_Store
./RemoteStuff/DDWRT/ddwrt-linksys-wrt1200acv2-webflash.bin
./RemoteStuff/DDWRT/ddwrt_mod_notes.docx
./RemoteStuff/DDWRT/factory-to-ddwrt.bin
./RemoteStuff/open_ldap_config_notes/
./RemoteStuff/open_ldap_config_notes/ldap_directory_a.png
./RemoteStuff/open_ldap_config_notes/open_ldap_notes.txt
./RemoteStuff/perl_scripts/
./RemoteStuff/perl_scripts/mysnmp.pl
./RemoteStuff/php_scripts/
./RemoteStuff/php_scripts/chunked.php
./RemoteStuff/php_scripts/gettingURL.php
./RemoteStuff/A Guide to the WordPress REST API | Toptal.pdf
./RemoteStuff/Rick Cardon Tech LLC.webloc
./RemoteStuff/VeeamDiagram.png
./RemoteStuff/backbox-4.5.1-i386.iso
./RemoteStuff/dhcp_admin_script_update.py
./RemoteStuff/test_file.txt
[rdc@mint Documents]$ ls -ld RemoteStuff.tgz
-rw-rw-r--. 1 rdc rdc 2317140451 Mar 12 06:10 RemoteStuff.tgz注意-すべてのファイルをアーカイブに直接追加する代わりに、フォルダー全体を_RemoteStuff_アーカイブしました。 これが最も簡単な方法です。 単純に、抽出時にディレクトリ_RemoteStuff_が抽出され、現在の作業ディレクトリ内のすべてのファイルが_./currentWorkingDirectory/RemoteStuff/_として抽出されます。
では、_/root/_ホームディレクトリ内のアーカイブを展開しましょう。
[root@centos ~]# tar -zxvf RemoteStuff.tgz
./RemoteStuff/
./RemoteStuff/.DS_Store
./RemoteStuff/DDWRT/
./RemoteStuff/DDWRT/.DS_Store
./RemoteStuff/DDWRT/ddwrt-linksys-wrt1200acv2-webflash.bin
./RemoteStuff/DDWRT/ddwrt_mod_notes.docx
./RemoteStuff/DDWRT/factory-to-ddwrt.bin
./RemoteStuff/open_ldap_config_notes/
./RemoteStuff/open_ldap_config_notes/ldap_directory_a.png
./RemoteStuff/open_ldap_config_notes/open_ldap_notes.txt
./RemoteStuff/perl_scripts/
./RemoteStuff/perl_scripts/mysnmp.pl
./RemoteStuff/php_scripts/
./RemoteStuff/php_scripts/chunked.php
./RemoteStuff/php_scripts/gettingURL.php
./RemoteStuff/A Guide to the WordPress REST API | Toptal.pdf
./RemoteStuff/Rick Cardon Tech LLC.webloc
./RemoteStuff/VeeamDiagram.png
./RemoteStuff/backbox-4.5.1-i386.iso
./RemoteStuff/dhcp_admin_script_update.py
./RemoteStuff/test_file.txt
[root@mint ~]# ping www.google.com上記のように、すべてのファイルは、現在の作業ディレクトリ内の格納ディレクトリに単純に抽出されました。
[root@centos ~]# ls -l
total 2262872
-rw-------. 1 root root 1752 Feb 1 19:52 anaconda-ks.cfg
drwxr-xr-x. 137 root root 8192 Mar 9 04:42 etc_baks
-rw-r--r--. 1 root root 1800 Feb 2 03:14 initial-setup-ks.cfg
drwxr-xr-x. 6 rdc rdc 4096 Mar 10 22:20 RemoteStuff
-rw-r--r--. 1 root root 2317140451 Mar 12 07:12 RemoteStuff.tgz
-rw-r--r--. 1 root root 9446 Feb 25 05:09 ssl.conf [root@centos ~]#gzipを使用してファイルバックアップを圧縮する
前述のとおり、-j *または *-z コマンドラインスイッチを使用して、tarからbzip2またはgzipを使用できます。 gzipを使用して個々のファイルを圧縮することもできます。 ただし、bzipまたはgzipを単独で使用しても、_tar_と組み合わせた場合ほど多くの機能は提供されません。
_gzip_を使用する場合、デフォルトのアクションは元のファイルを削除し、それぞれを.gz拡張子を追加した圧縮バージョンに置き換えます。
gzipの一般的なコマンドラインスイッチは次のとおりです-
| Switch | Action |
|---|---|
| -c | Keeps files after placing into the archive |
| -l | Get statistics for the compressed archive |
| -r | Recursively compresses files in the directories |
| -1 thru 9 | Specifies the compression level on a scale of 1 thru 9 |
いくつかのWindows O/S zipユーティリティのようなアーカイブ単位ではなく、ファイル単位で多かれ少なかれ_gzip_が機能します。 この主な理由は、_tar_がすでに高度なアーカイブ機能を提供しているためです。 _gzip_は、圧縮メカニズムのみを提供するように設計されています。
したがって、_gzip_を考えるときは、単一のファイルを考えてください。 複数のファイルを考えるときは、_tar_アーカイブを考えてください。 これを以前の_tar_アーカイブで調べてみましょう。
注-熟練したLinuxの専門家は、tarアーカイブをtarballと呼ぶことがよくあります。
_rsync_バックアップから別の_tar_アーカイブを作成しましょう。
[root@centos Documents]# tar -cvf RemoteStuff.tar ./RemoteStuff/
[root@centos Documents]# ls
RemoteStuff.tar RemoteStuff/デモンストレーションのために、新しく作成したtarballを_gzip_し、gzip_に古いファイルを保持するように指示します。 デフォルトでは、- c_オプションなしで、gzipはtarアーカイブ全体を_.gz_ファイルに置き換えます。
[root@centos Documents]# gzip -c RemoteStuff.tar > RemoteStuff.tar.gz
[root@centos Documents]# ls
RemoteStuff RemoteStuff.tar RemoteStuff.tar.gz
We now have our original directory, our tarred directory and finally our gziped tarball.gzip_を使用して-l_スイッチをテストしてみましょう。
[root@centos Documents]# gzip -l RemoteStuff.tar.gz
compressed uncompressed ratio uncompressed_name
2317140467 2326661120 0.4% RemoteStuff.tar
[root@centos Documents]#_gzip_がWindows Zipユーティリティとどのように異なるかを示すために、テキストファイルのフォルダーでgzipを実行してみましょう。
[root@centos Documents]# ls text_files/
file1.txt file2.txt file3.txt file4.txt file5.txt
[root@centos Documents]#次に、-rオプションを使用して、ディレクトリ内のすべてのテキストファイルを再帰的に圧縮します。
[root@centos Documents]# gzip -9 -r text_files/
[root@centos Documents]# ls ./text_files/
file1.txt.gz file2.txt.gz file3.txt.gz file4.txt.gz file5.txt.gz
[root@centos Documents]#See? 予想していたものではありません。 元のテキストファイルはすべて削除され、それぞれが個別に圧縮されました。 この動作のため、単一ファイルで作業する必要がある場合は、_gzip_のみを考えるのが最善です。
tarballs_を使用して、_rsynced tarballを新しいディレクトリに抽出しましょう。
[root@centos Documents]# tar -C/tmp -zxvf RemoteStuff.tar.gz
./RemoteStuff/
./RemoteStuff/.DS_Store
./RemoteStuff/DDWRT/
./RemoteStuff/DDWRT/.DS_Store
./RemoteStuff/DDWRT/ddwrt-linksys-wrt1200acv2-webflash.bin
./RemoteStuff/DDWRT/ddwrt_mod_notes.docx
./RemoteStuff/DDWRT/factory-to-ddwrt.bin
./RemoteStuff/open_ldap_config_notes/
./RemoteStuff/open_ldap_config_notes/ldap_directory_a.png
./RemoteStuff/open_ldap_config_notes/open_ldap_notes.txt
./RemoteStuff/perl_scripts/
./RemoteStuff/perl_scripts/mysnmp.pl
./RemoteStuff/php_scripts/
./RemoteStuff/php_scripts/chunked.php上記のように、tarballを/tmpディレクトリに解凍して解凍しました。
[root@centos Documents]# ls/tmp
hsperfdata_root
RemoteStuffTarBallアーカイブの暗号化
災害復旧の場合に、組織の他の従業員がアクセスする必要のある安全なドキュメントを保存するためにtarballアーカイブを暗号化することは、扱いにくいコンセプトです。 これを行うには、基本的に3つの方法があります。GnuPGを使用するか、opensslを使用するか、サードパーティのユーティリティを使用します。
GnuPGは主に非対称暗号化用に設計されており、パスフレーズではなくID関連付けを念頭に置いています。 確かに、対称暗号化で使用できますが、これはGnuPGの主な長所ではありません。 したがって、元の人よりも多くの人がアクセスを必要とする場合は、物理的なセキュリティでアーカイブを保存するためにGnuPGを割引します（王国のすべてのキーをレバレッジとして保持している管理者から保護したい企業マネージャーなど）。
GnuPGのようなOpensslは、私たちが望むことをすることができ、CentOSに同梱されています。 しかし、繰り返しますが、私たちが望むことをするように特別に設計されたものではなく、セキュリティコミュニティでは暗号化が疑問視されています。
私たちの選択は、 7zip と呼ばれるユーティリティです。 7zipは_gzip_に似た圧縮ユーティリティですが、さらに多くの機能があります。 Gnu Gzipと同様に、7zipとその標準はオープンソースコミュニティにあります。 EHELリポジトリから7zipをインストールするだけです（次の章では、拡張エンタープライズリポジトリのインストールについて詳しく説明します）。
CentOSに7zipをインストールする
7zipは、EHELリポジトリがCentOSに読み込まれて設定されると、簡単にインストールできます。
[root@centos Documents]# yum -y install p7zip.x86_64 p7zip-plugins.x86_64
Loaded plugins: fastestmirror, langpacks
base
| 3.6 kB 00:00:00
epel/x86_64/metalink
| 13 kB 00:00:00
epel
| 4.3 kB 00:00:00
extras
| 3.4 kB 00:00:00
updates
| 3.4 kB 00:00:00
(1/2): epel/x86_64/updateinfo
| 756 kB 00:00:04
(2/2):
epel/x86_64/primary_db
| 4.6 MB 00:00:18
Loading mirror speeds from cached hostfile
--> Running transaction check
---> Package p7zip.x86_64 0:16.02-2.el7 will be installed
---> Package p7zip-plugins.x86_64 0:16.02-2.el7 will be installed
--> Finished Dependency Resolution
Dependencies Resolved簡単なことですが、7zipがインストールされており、tarballアーカイブ用に256ビットAES暗号化ですぐに使用できます。
7zを使用して、gzip圧縮されたアーカイブをパスワードで暗号化します。 そうするための構文は非常に簡単です-
7z a -p <output filename><input filename>ここで、* a：アーカイブに追加し、-p：*暗号化してパスフレーズを要求します
[root@centos Documents]# 7z a -p RemoteStuff.tgz.7z RemoteStuff.tar.gz
7-Zip [64] 16.02 : Copyright (c) 1999-2016 Igor Pavlov : 2016-05-21
p7zip Version 16.02 (locale=en_US.UTF-8,Utf16=on,HugeFiles=on,64 bits,1 CPU Intel(R)
Core(TM) i5-4278U CPU @ 2.60GHz (40651),ASM,AES-NI)
Scanning the drive:
1 file, 2317140467 bytes (2210 MiB)
Creating archive: RemoteStuff.tgz.7z
Items to compress: 1
Enter password (will not be echoed):
Verify password (will not be echoed) :
Files read from disk: 1
Archive size: 2280453410 bytes (2175 MiB)
Everything is Ok
[root@centos Documents]# ls
RemoteStuff RemoteStuff.tar RemoteStuff.tar.gz RemoteStuff.tgz.7z slapD
text_files
[root@centos Documents]#これで、gzip圧縮されたtarballを256ビットAESで暗号化する.7zアーカイブができました。
注意-7zipは、パスワードとカウンターのSHA-256ハッシュを使用したAES 256ビット暗号化を使用し、キーの導出のために最大512K回繰り返されます。 複雑なキーが使用される場合、これは十分に安全でなければなりません。
アーカイブの暗号化と再圧縮のプロセスは、より大きなアーカイブではさらに時間がかかる場合があります。
7zipは、gzipやbzip2よりも多くの機能を備えた高度な製品です。 ただし、CentOSまたはLinuxの世界では標準ではありません。 したがって、他のユーティリティはできるだけ頻繁に使用する必要があります。
