マイクロソフトは日本時間11月19日未明に開幕した年次インベント「Microsoft Iginte 2025」で、ミッションクリティカルに対応したPostgreSQLのデータベースサービス「Azure HorizonDB」を発表しました。
［速報］マイクロソフト、ミッションクリティカルに対応するスケーラブルなPostgreSQL「Azure HorizonDB」発表。Ignite 2025 － Publickey
Azure HorizonDBは高性能なPostgreSQLのマネージドサービスです。プライマリノードとレプリカノードのノード全体で最大3072vCPUまでスケールアウト可能なスケーラビリティと、最大で128TBまでオートスケールするストレージは、マルチゾーン構成でミリ秒以下のレイテンシを実現しています。
［速報］マイクロソフト、ミッションクリティカルに対応するスケーラブルなPostgreSQL「Azure HorizonDB」発表。Ignite 2025 － Publickey
マイクロソフトはこれにより通常のPostgreSQLと比較して最大で3倍のトランザクション性能を発揮するとしています。
［速報］マイクロソフト、ミッションクリティカルに対応するスケーラブルなPostgreSQL「Azure HorizonDB」発表。Ignite 2025 － Publickey
⇧ う～む...、料金が気になりますな...
スケーラビリティ（scalability）とは利用者や仕事の増大に適応できる能力・度合いのこと。電気通信やソフトウェア工学において、システムまたはネットワークまたはアルゴリズムの、持つべき望ましい特性の1つで、一種の拡張性である。
スケールアップとスケールアウト
スケールアップ（垂直スケール）やスケールアウト（水平スケール）は、スケーラビリティの向上、すなわち性能・容量向上のための方法である。
スケールアウトはシステムにノードを追加することで、クラスタなどの並列コンピューティング技術を使用する方法である。
現実のシステムではそれぞれ上限・制約・デメリットも存在するため、組み合わせも行われる。
⇧ 上記にある通り、「スケールアウト」は、台数を増設する方式なので、「Azure HorizonDB」は、ノードの総数のMaxサイズが「128 TiB」という上限になるっぽいということですかね。1ノードあたりのサイズはどのぐらいにすべきなのだろうか？
面倒な「保守・運用」を「Microsoft Azure」側にお任せできて、且つ、オンプレミス環境という制約が無いのであれば、利用したいところだが、料金（コスト）がなぁ...
ただ、「データ」の管理を「クラウドサービスプロバイダー」に依存させるのは微妙と言うこともありますからなぁ...
オーストリアの連邦経済エネルギー観光省(BMWET)が、アメリカの企業であるMicrosoftから脱却してドイツに拠点を置くNextcloudの製品に乗り換えることを明らかにしました。Nextcloudはオープンソースソフトウェアであることが最大の特徴です。
発表によると、BMWETはわずか4カ月間でNextcloudの概念実証から運用開始までこぎつけ、既存のMicrosoft製品に変わるシステムとして活用しているとのこと。Nextcloudはオーストリア国内のインフラ上で運用されており、欧州以外のプロバイダーに依存する際に生じていた法的およびセキュリティ面での不確実性が回避される見込みです。
⇧ 欧州だと、脱「Microsoft」が一部で進んでいるっぽいという話がある...
「リスクヘッジ」という意味では、国内の基幹システムが扱う「データ」は国内産の「サービス」を利用した方が良さそうではあるが、
⇧ 上記の取り組みで、「国内外」の「クラウドサービスプロバイダー」のごった煮みたいな状況になっていた気が...
何となくだが、「ガバメントクラウド」の内情としては、危うい状態ではありそうに思えてしまいますな...
ChatGPTにrsyncとsshpassでファイル転送の処理をお願いしてみた
前回、
⇧ scpでのファイル転送について整理したのだが、
リモートサーバーとファイルをやり取りできる「scp」コマンドは、システム管理やソフトウェア開発の現場で長年親しまれてきましたが、オープンソースのSSH実装「OpenSSH」の最新版では利用を控えるべきとされています。手軽にサーバー間のファイル操作を行えるscpが非推奨とされた理由について、Linux開発者のジョナサン・コルベット氏が説明しています。
開発者たちが慣れ親しんだ「scp」コマンドはなぜ「時代遅れで柔軟性がなくすぐに修正できない」のか？ - GIGAZINE
「scpが可能なサーバーはSSH接続による操作も可能なのだから、コマンドが実行できても問題ない」という考え方もありますが、scpのみを許可したいサーバーでは問題になるとコルベット氏。scpは設計が非常に古いため、新しいセキュリティ機能の追加やプログラムの修正が難しいとされており、OpenSSHはscpについて「時代遅れで、柔軟性がなくすぐに修正できない」プロトコルだと表明しています。
開発者たちが慣れ親しんだ「scp」コマンドはなぜ「時代遅れで柔軟性がなくすぐに修正できない」のか？ - GIGAZINE
古くなったscpの代替として推奨されているコマンドが「sftp」や「rsync」コマンドです。特にsftpコマンドはOpenSSHパッケージに含まれており、追加のパッケージなしで利用することが可能です。
開発者たちが慣れ親しんだ「scp」コマンドはなぜ「時代遅れで柔軟性がなくすぐに修正できない」のか？ - GIGAZINE
⇧ 何と言うか、「Linux ディストリビューション」のデフォルトのインストール状態で、
- sftp
- rsync
が同梱されているのならば良いのだが、別途、インストールが必要なんでしょ？
環境によっては、パッケージのインストール禁止とかもありますしな...
ネットの情報を漁っていたところ、
⇧ 上記サイト様でも、
- sftp
- rsync
の利用が奨励されている話が紹介されていた。
とりあえず、
⇧ 上記サイト様によりますと、認証情報の入力が求められるようなので、「sshpass」で認証情報の入力のプロンプトを省略できるようにする必要がありますと。
というわけで、今回は、
- rsync
- sshpass
がインストールできる環境という前提で、「ChatGPT」氏に「rsync」を利用したファイル転送のシェルスクリプトの実装をお願いしてみた。
🔹 サーバーA → サーバーB 完全自動スクリプト
1️⃣ サーバーA側スクリプト（transfer_tar_auto_retry.sh）
このスクリプトでは、rsync の転送速度を確認するために --progress と --stats オプションを利用します。また、転送速度をログに記録するために tee を使用します。
■サーバーA側スクリプトの流れ
-
tar.gzの作成
圧縮対象となるディレクトリ（/path/to/source）をtarコマンドでarchive.tar.gzという名前で圧縮します。 -
SHA256 ハッシュの作成
圧縮したarchive.tar.gzの SHA256 ハッシュをarchive.tar.gz.sha256として保存します。 -
ファイルの分割
splitコマンドを使用して、圧縮ファイル（archive.tar.gz）を指定サイズ（4Gなど）で分割します。分割ファイルはpart_aa、part_abのように作成されます。 -
分割ファイルごとの SHA256 ハッシュ作成
分割ファイルの SHA256 ハッシュをparts.sha256として作成します。このファイルにはpart_aa、part_abの各ハッシュが記録されます。 -
rsync を使ってサーバーBへ転送
sshpassを使って、rsyncコマンドで分割ファイル、parts.sha256、およびarchive.tar.gz.sha256をサーバーBに転送します。
転送中の進行状況は--progressで表示され、詳細な統計情報は--statsで出力されます。
#!/bin/bash
set -e
# ---------------------------
# 設定
# ---------------------------
SRC_DIR="/path/to/source" # 圧縮する元のディレクトリ
ARCHIVE_NAME="archive.tar.gz" # 圧縮後のファイル名
SPLIT_SIZE="4G" # 分割サイズ
REMOTE_USER="user" # サーバーBのユーザー名
REMOTE_HOST="serverB" # サーバーBのホスト名またはIPアドレス
REMOTE_DIR="/data/archive" # サーバーBの保存先ディレクトリ
SSH_PASS="PASSWORD" # サーバーBのパスワード
WORKDIR="/tmp/archive_work" # 作業ディレクトリ
MAX_RETRIES=5 # 転送失敗時の最大再試行回数
LOG_FILE="/tmp/rsync_transfer.log" # 転送ログファイル
# ---------------------------
# 1. 作業ディレクトリ作成
echo "=== 1. 作業ディレクトリ作成 ==="
mkdir -p "$WORKDIR"
cd "$WORKDIR"
# ---------------------------
# 2. tar.gz 作成
# ---------------------------
echo "=== 2. tar.gz 圧縮作成 ==="
tar -czvf "$ARCHIVE_NAME" -C "$(dirname "$SRC_DIR")" "$(basename "$SRC_DIR")"
# ---------------------------
# 3. SHA256 ハッシュ作成
# ---------------------------
echo "=== 3. SHA256 ハッシュ生成 ==="
sha256sum "$ARCHIVE_NAME" > "$ARCHIVE_NAME.sha256"
# ---------------------------
# 4. 分割
# ---------------------------
echo "=== 4. 分割ファイル作成 ==="
split -b "$SPLIT_SIZE" "$ARCHIVE_NAME" part_
# ---------------------------
# 5. 分割ファイルの SHA256 ハッシュ作成
# ---------------------------
echo "=== 5. 分割ファイルの SHA256 ハッシュ作成 ==="
sha256sum part_* > parts.sha256
# ---------------------------
# 6. rsync でサーバーBへ転送（自動再開・再試行対応）
# ---------------------------
echo "=== 6. rsync でサーバーBへ転送 ==="
COUNT=0
TRANSFER_SUCCESS=false
while [ $COUNT -lt $MAX_RETRIES ]; do
# rsyncコマンドで転送を行い、進行状況と統計情報をログファイルに記録
sshpass -p "$SSH_PASS" rsync -av --partial --append-verify --progress --stats --info=progress2 \
-e "ssh -o StrictHostKeyChecking=no -o Compression=no" \
part_* "$ARCHIVE_NAME.sha256" parts.sha256 "$REMOTE_USER@$REMOTE_HOST:$REMOTE_DIR" | tee -a "$LOG_FILE"
# rsync の終了コードが 0 であれば成功
if [ $? -eq 0 ]; then
TRANSFER_SUCCESS=true
break
else
COUNT=$((COUNT + 1))
echo "転送失敗、再試行 $COUNT/$MAX_RETRIES"
sleep 5
fi
done
# 転送失敗時の処理
if [ "$TRANSFER_SUCCESS" = false ]; then
echo "転送に失敗しました。手動確認が必要です。"
exit 1
fi
# ---------------------------
# 7. 作業ディレクトリ削除
# ---------------------------
echo "=== 7. 作業ディレクトリ削除 ==="
cd /
rm -rf "$WORKDIR"
echo "=== 完了 ==="
echo "サーバーBで結合と検証を行ってください。"
2️⃣ サーバーB側スクリプト（combine_verify_auto.sh）
サーバーB側では、受け取った分割ファイルを結合し、SHA256で検証した後、作業ディレクトリを削除します。
■サーバーB側スクリプトの流れ
-
作業ディレクトリ作成
-
分割ファイルを受け取る
サーバーAから転送された分割ファイル、ハッシュファイル（parts.sha256とarchive.tar.gz.sha256）を作業ディレクトリにコピーします。 -
分割ファイルごとの整合性確認
転送された分割ファイルが正しいかどうか、parts.sha256を使ってチェックします。 -
分割ファイルを結合
問題がなければ、分割ファイルをcatコマンドで結合し、元のアーカイブファイルを再構築します。 -
結合後のファイルの整合性確認
結合したアーカイブファイルが、サーバーAで作成したハッシュファイル（archive.tar.gz.sha256）と一致するかを確認します。 -
結合後ファイルを保存ディレクトリへ移動
#!/bin/bash set -e # --------------------------- # 設定 # --------------------------- REMOTE_DIR="/data/archive" # 保存先ディレクトリ WORKDIR="/tmp/archive_work_b" # 作業ディレクトリ ARCHIVE_NAME="archive.tar.gz" # 結合後のファイル名 MAX_RETRIES=5 # 再試行回数（必要な場合） LOG_FILE="/tmp/rsync_receive.log" # 転送ログファイル # --------------------------- # 1. 作業ディレクトリ作成 echo "=== 1. 作業ディレクトリ作成 ===" mkdir -p "$WORKDIR" cd "$WORKDIR" # --------------------------- # 2. 分割ファイルとハッシュを受け取る # --------------------------- echo "=== 2. 分割ファイルとハッシュをコピー ===" cp "$REMOTE_DIR"/part_* . cp "$REMOTE_DIR/parts.sha256" . cp "$REMOTE_DIR/$ARCHIVE_NAME.sha256" . # --------------------------- # 3. 分割ファイルごとのハッシュチェック # --------------------------- echo "=== 3. 分割ファイルの整合性確認（SHA256チェック） ===" sha256sum -c parts.sha256 # --------------------------- # 4. 分割ファイルを結合 # --------------------------- echo "=== 4. 分割ファイルを結合 ===" cat part_* > "$ARCHIVE_NAME" # --------------------------- # 5. 結合後ファイルのハッシュチェック # --------------------------- echo "=== 5. 結合後のファイルのSHA256チェック ===" sha256sum -c "$ARCHIVE_NAME.sha256" # --------------------------- # 6. 結合後ファイルを保存ディレクトリへ移動 # --------------------------- echo "=== 6. 結合後ファイルを保存ディレクトリへ移動 ===" mv "$ARCHIVE_NAME" "$REMOTE_DIR/" # --------------------------- # 7. 作業ディレクトリ削除 # --------------------------- echo "=== 7. 作業ディレクトリ削除 ===" cd / rm -rf "$WORKDIR" echo "=== 完了 ==="
■各々のサーバーの必要ディスク容量
1. サーバーA側
作業内容
-
元データを tar.gz に圧縮 → 200 GiB
-
tar.gz を分割 → part_* ファイル（合計 200 GiB）
-
SHA256 ハッシュ作成 → 数百 MB（無視できる程度）
-
rsync でサーバーBに転送
必要ディスク容量
-
圧縮ファイル: 200 GiB
-
分割ファイル: 200 GiB
-
合計（最大同時に存在する場合）: 約 400 GiB
注意: 圧縮ファイルと分割ファイルが同時に作業ディレクトリに存在するため、作業ディレクトリには 最大で 400 GiB 程度 が必要です。
2. サーバーB側
作業内容
-
サーバーAから part_* を受け取り作業ディレクトリにコピー → 200 GiB
-
SHA256 チェック（ファイルを検証）
-
分割ファイルを結合 → archive.tar.gz（200 GiB）
-
結合後ファイルの SHA256 チェック
必要ディスク容量
-
分割ファイル: 200 GiB
-
結合後のファイル: 200 GiB
-
合計（最大同時に存在する場合）: 約 400 GiB
注意: 分割ファイルと結合後ファイルが同時に作業ディレクトリに存在するため、作業ディレクトリには 最大 400 GiB 程度 の空きが必要です。
まとめ
| No | 用途 | サーバーA | サーバーB |
|---|---|---|---|
| 1 | 圧縮前 | 2 TiB（2048 GiB） | - |
| 2 | 圧縮後 | 200 GiB | - |
| 3 | ファイル分割後 | 200 GiB | - |
| 4 | 転送後 | - | 200 GiB |
| 5 | ファイル結合後 | - | 200 GiB |
| 6 | 展開（解凍）後 | - | 2 TiB（2048 GiB） |
| 7 | 必要ディスク容量の合計 | 2448 GiB | 2448 GiB |
⇧ 動作確認は未了なのだが、流石に、複雑な設計の実装というわけでもないので「幻覚（ハルシネーション）」は引き起こしていないと信じたい。
200 GiBの容量のファイル転送をするとなると、転送されてきたファイルの結合、展開（解凍）も考慮すると、一時的にとはいえ、約2450 GiBほどのディスク容量が必要になると...
ちなみに、「tar.gz」のファイル圧縮率について、「ChatGPT」氏に質問してみたところ、以下のような回答が返ってきた。
■tar.gz 圧縮オプションによる圧縮率マトリックス（オプション -1 から -9）
| ファイルの種類 | gzip -1 (最速) | gzip -3 | gzip -5 | gzip -7 | gzip -9 (最圧縮) |
|---|---|---|---|---|---|
| テキストファイル | 50% 〜 70% | 60% 〜 75% | 65% 〜 80% | 70% 〜 85% | 75% 〜 90% |
| ソースコードファイル | 40% 〜 60% | 50% 〜 70% | 55% 〜 75% | 60% 〜 80% | 65% 〜 85% |
| CSV / TSVファイル | 50% 〜 70% | 55% 〜 75% | 60% 〜 80% | 65% 〜 85% | 70% 〜 90% |
| ログファイル | 30% 〜 50% | 40% 〜 60% | 45% 〜 65% | 50% 〜 70% | 55% 〜 75% |
| 画像ファイル（JPEG, PNG） | 10% 〜 30% | 15% 〜 35% | 20% 〜 40% | 25% 〜 45% | 30% 〜 50% |
| 動画ファイル（MP4, AVI） | 5% 〜 15% | 8% 〜 18% | 10% 〜 20% | 12% 〜 25% | 15% 〜 30% |
| 音声ファイル（MP3, WAV） | 10% 〜 25% | 15% 〜 30% | 20% 〜 35% | 25% 〜 40% | 30% 〜 50% |
| 圧縮済みファイル（ZIP, RAR） | 1% 〜 5% | 2% 〜 7% | 3% 〜 8% | 4% 〜 10% | 5% 〜 15% |
| バイナリファイル（実行ファイル） | 10% 〜 25% | 15% 〜 30% | 20% 〜 35% | 25% 〜 40% | 30% 〜 50% |
■具体例：ファイルの種類ごとの圧縮率と処理時間
| ファイルの種類 | gzip -1 (最速) | gzip -3 | gzip -5 | gzip -7 | gzip -9 (最圧縮) |
|---|---|---|---|---|---|
| テキストファイル | 圧縮率: 50% 〜 70% | 圧縮率: 60% 〜 75% | 圧縮率: 65% 〜 80% | 圧縮率: 70% 〜 85% | 圧縮率: 75% 〜 90% |
| 処理時間: 速い | 処理時間: 中 | 処理時間: 中 | 処理時間: 遅い | 処理時間: 非常に遅い | |
| ソースコードファイル | 圧縮率: 40% 〜 60% | 圧縮率: 50% 〜 70% | 圧縮率: 55% 〜 75% | 圧縮率: 60% 〜 80% | 圧縮率: 65% 〜 85% |
| 処理時間: 速い | 処理時間: 中 | 処理時間: 中 | 処理時間: 遅い | 処理時間: 非常に遅い | |
| CSV / TSVファイル | 圧縮率: 50% 〜 70% | 圧縮率: 55% 〜 75% | 圧縮率: 60% 〜 80% | 圧縮率: 65% 〜 85% | 圧縮率: 70% 〜 90% |
| 処理時間: 速い | 処理時間: 中 | 処理時間: 中 | 処理時間: 遅い | 処理時間: 非常に遅い | |
| ログファイル | 圧縮率: 30% 〜 50% | 圧縮率: 40% 〜 60% | 圧縮率: 45% 〜 65% | 圧縮率: 50% 〜 70% | 圧縮率: 55% 〜 75% |
| 処理時間: 速い | 処理時間: 中 | 処理時間: 中 | 処理時間: 遅い | 処理時間: 非常に遅い | |
| 画像ファイル | 圧縮率: 10% 〜 30% | 圧縮率: 15% 〜 35% | 圧縮率: 20% 〜 40% | 圧縮率: 25% 〜 45% | 圧縮率: 30% 〜 50% |
| 処理時間: 速い | 処理時間: 中 | 処理時間: 中 | 処理時間: 遅い | 処理時間: 非常に遅い | |
| 動画ファイル | 圧縮率: 5% 〜 15% | 圧縮率: 8% 〜 18% | 圧縮率: 10% 〜 20% | 圧縮率: 12% 〜 25% | 圧縮率: 15% 〜 30% |
| 処理時間: 速い | 処理時間: 中 | 処理時間: 中 | 処理時間: 遅い | 処理時間: 非常に遅い | |
| 音声ファイル | 圧縮率: 10% 〜 25% | 圧縮率: 15% 〜 30% | 圧縮率: 20% 〜 35% | 圧縮率: 25% 〜 40% | 圧縮率: 30% 〜 50% |
| 処理時間: 速い | 処理時間: 中 | 処理時間: 中 | 処理時間: 遅い | 処理時間: 非常に遅い | |
| 圧縮済みファイル | 圧縮率: 1% 〜 5% | 圧縮率: 2% 〜 7% | 圧縮率: 3% 〜 8% | 圧縮率: 4% 〜 10% | 圧縮率: 5% 〜 15% |
| 処理時間: 非常に速い | 処理時間: 速い | 処理時間: 中 | 処理時間: 中 | 処理時間: 遅い | |
| バイナリファイル | 圧縮率: 10% 〜 25% | 圧縮率: 15% 〜 30% | 圧縮率: 20% 〜 35% | 圧縮率: 25% 〜 40% | 圧縮率: 30% 〜 50% |
| 処理時間: 速い | 処理時間: 中 | 処理時間: 中 | 処理時間: 遅い | 処理時間: 非常に遅い |
「ChatGPT」氏に、具体的な例を整理してもらった。
■圧縮後サイズの計算結果
以下に、圧縮率別に 2 TiB のファイルが圧縮された場合の圧縮後サイズを計算した結果をまとめます。
| 圧縮率 | 計算式 | 圧縮後サイズ |
|---|---|---|
| 10% | 2048 × (1 - 0.10) = 2048 × 0.90 | 1843.2 GiB |
| 20% | 2048 × (1 - 0.20) = 2048 × 0.80 | 1638.4 GiB |
| 30% | 2048 × (1 - 0.30) = 2048 × 0.70 | 1433.6 GiB |
| 40% | 2048 × (1 - 0.40) = 2048 × 0.60 | 1228.8 GiB |
| 50% | 2048 × (1 - 0.50) = 2048 × 0.50 | 1024.0 GiB |
| 60% | 2048 × (1 - 0.60) = 2048 × 0.40 | 819.2 GiB |
| 70% | 2048 × (1 - 0.70) = 2048 × 0.30 | 614.4 GiB |
| 80% | 2048 × (1 - 0.80) = 2048 × 0.20 | 409.6 GiB |
| 90% | 2048 × (1 - 0.90) = 2048 × 0.10 | 204.8 GiB |
「pg_basebackup」のドキュメントを確認した限り、
⇧ 上記にある通り、「tar.gz」の「圧縮率」が適用できるらしい。
あと、
説明
pg_basebackupは、稼動中のPostgreSQLのデータベースクラスタのベースバックアップを取るために使用されます。 データベースへの他のクライアントに影響することなく、バックアップが取られます。
https://www.postgresql.jp/document/12/html/app-pgbasebackup.html
⇧ という記述をどう解釈すれば良いか分からないのだが、「デッドロック（deadlock）」が発生している状態でも支障なく「バックアップ」が取得できるという認識で良いのだろうか？
とりあえず、「ChatGPT」氏にシミュレーションしてもらった。
1. 前提条件
-
元のファイルサイズ: 2 TiB = 2048 GiB
-
CPU: 2〜8コアでの一般的なサーバーを想定（圧縮はシングルスレッドで計算）
-
ディスク: SSD と仮定
-
gzip の圧縮レベル別の速度目安（GiB/s、圧縮レベルが大きいほど遅くなる）：
| 圧縮レベル | 圧縮率目安 | 1コア速度 (GiB/s) |
|---|---|---|
| -1 | 10% | 0.15 |
| -2 | 20% | 0.14 |
| -3 | 30% | 0.13 |
| -4 | 40% | 0.11 |
| -5 | 50% | 0.10 |
| -6 | 60% | 0.09 |
| -7 | 70% | 0.08 |
| -8 | 80% | 0.07 |
| -9 | 90% | 0.06 |
これは SSD かつ CPU 性能の中程度のサーバーを想定した目安です。HDD や低性能 CPU ではさらに遅くなります。
2. 処理時間の計算式
処理時間[h] = 元サイズ ÷ (CPUコア数 × 1コア速度) ÷ 3600
3. 2 TiB（2048 GiB） ファイルの処理時間目安
| 圧縮レベル | 圧縮率目安 | 圧縮後サイズ (GiB) | CPU 2コア (h) | CPU 4コア (h) | CPU 8コア (h) |
|---|---|---|---|---|---|
| -1 | 10% | 1843 | 1.90 | 0.95 | 0.48 |
| -2 | 20% | 1638 | 2.57 | 1.29 | 0.64 |
| -3 | 30% | 1434 | 3.05 | 1.53 | 0.76 |
| -4 | 40% | 1229 | 4.03 | 2.01 | 1.01 |
| -5 | 50% | 1024 | 5.11 | 2.55 | 1.28 |
| -6 | 60% | 819 | 6.32 | 3.16 | 1.58 |
| -7 | 70% | 614 | 8.55 | 4.28 | 2.14 |
| -8 | 80% | 410 | 10.95 | 5.48 | 2.74 |
| -9 | 90% | 205 | 18.80 | 9.40 | 4.70 |
注意: 秒→時間に換算しました（1時間 ≈ 3600秒）。 この計算は単純計算で、実際は I/O や CPU 使用率によってさらに変動します。
✅ 特徴
-
圧縮率が高いほど圧縮後サイズは小さくなる
-
圧縮レベルが高くなるほど CPU 負荷が増える → 処理時間は長くなる
-
CPUコア数が増えると処理時間はほぼ比例して短縮される
え～っと...、圧縮処理の時間が本当に正しいのか謎過ぎる...
正確な処理時間の見積もりをしたいので、事実を述べて欲しいだけなのだが、「AI」のお得意の「幻覚（ハルシネーション）」を引き起こしているんかな...
これに加えて、
- ファイル分割
- ファイル転送
の処理時間がかかるとか、絶望的なのだが...
ファイル転送先では、
- ファイルチェック（分割した状態のファイル）
- ファイル結合
- ファイルチェック（結合後のファイル）
の処理時間が発生するわけですからな...
ちなみに、「ChatGPT」氏に、『適切なファイル分割のサイズを教えて』と質問してみたところ、以下のような回答が返ってきた。
✅ 結論（実務的な目安）
| ネットワーク環境 | 推奨される分割サイズ |
|---|---|
| 安定した LAN | 10〜50 GiB |
| WAN / VPN / インターネット経由 | 1〜5 GiB |
| かなり不安定な環境 | 500 MiB〜1 GiB |
📌 なぜ分割するのか？
rsync は差分転送や再開が得意ですが、
-
巨大ファイルは転送中断時の再開が遅くなる
-
複数 CPU コアを有効活用しづらい
-
ファイル 1 個が巨大だと I/O が偏る
-
ネットワークの揺らぎに弱い
などの理由で、実務ではあえて分割されることがあります。
📌 一般的に一番バランスが良いサイズ
1〜5 GiB が最も一般的でトラブルが少ないサイズ
特に WAN 経由ならこのサイズが安定し、再送コストも低いです。
📌 もし分割しない場合の注意点
200GiB のファイルをそのまま rsync する場合、
-
--partialを必ずつける（途中から再開するため） -
--inplaceは用途に応じて検討（差分適用が速いが破損リスク） -
メモリ消費を抑えるため
--no-whole-fileを活用（LAN では逆）
📌 まとめ
-
1〜5 GiB が最も無難
-
安定したLANならもっと大きくてもOK（10〜50 GiB）
-
不安定な回線ほど小さくする（500 MiB〜1 GiB）
う～む...、最大でも、1ファイルあたり500 MiB ぐらいのサイズになるように分割した方が無難なのかな...
「rsync」ならファイルを分割しないで途中で転送が失敗した場合でも、途中から処理を再開してくれるらしいが...
悩ましい...
毎度モヤモヤ感が半端ない…
今回はこのへんで。
