☰

2 つの位置間のデータ同期

tag-icon • tag-icon rsync synchronization data
2 つの位置間のデータ同期

データが多い場所に行かなければなりません。どちらの場所もインターネット接続が遅かった。したがって、インターネットを介して2つの場所間でデータを同期することは不可能です。だからアイデアは、スニーカーネットワークを使用してデータを同期することです。

A場所にいるときは、NVMEドライブをサーバーに接続します。去るときは運転をします。 B位置にいるときは、ドライブを別のサーバーに接続します。

それでは、データを同期する最良の方法は何ですか？

sneakerssyncプロジェクトを見つけました。https://github.com/lamyj/sneakersync しかし、このプロジェクトにはいくつかの制限がないため、私には適していません。

  1. 当初、同期するデータは約45TBでした。しかし、NVMEの時間とスペースは限られています。
  2. 同期は2つの方法で機能する必要があります。スレーブサーバA=>BおよびスレーブサーバB=>A.

ベストアンサー1

もしあなたなら持つインターネット接続を使用すると、数時間で45TBの約1/2000を転送できます。rsync「セミオフライン」アップデートのための友達です！これは、インターネット接続がファイル名、属性、およびチェックサムを交換し、必要な変更をファイルに書き込むためにのみ使用され、他の方法で転送できることを意味します。

Aでは、

#     Only update files that are newer on A than on B
#     |  archive mode: keep times, owners, permissions
#     |  |     Don't actually send data over network, but write to file "batch-updates.archive"
#     |  |     |                                        Go through subdirectories
#     |  |     |                                        |           Show progress
#     |  |     |                                        |           |          |----copy from here----| |----copy to here on B----|
rsync -u -a    --only-write-batch=AforB-updates.archive --recursive --progress "${path_to_Alocalfiles}" "B:${path_to_Blocalfiles}"
# If batch update file is large: compress strongly if necessary
# Lower levels than -15 are much faster than typical SSD write speed (try -4),
# so compression is a pure win-win situation here.
zstd -T0 -15 AforB-updates.archive

強力な帰還ハトをBに配置し、Aに移動し、含まれているNVMeをステープルで固定し、AforB-updates.archive.zstNVMeをBに戻します。一方、B では、上記の A と同じ操作を実行して B -> 更新を取得します。

rsync --update -a --only-write-batch=BforA-updates.archive --recursive --progress "${path_to_Blocalfiles}" "A:${path_to_Alocalfiles}"
zstd -T0 -15 BforA-updates.archive

鳩に餌をやってください。

完了したらBで

zstd -T0 --stdout -d AforB-updates.archive.zstd | rsync --read-batch=- -a "${path_to_Blocalfiles}"

NVMeにコピーしBforA-updates.archive.zst、地下室からOLE SSDエジェクタを取り出し、NVMeを3つのタオルで包み、BからAに、そして再び発射し、最後にzstd -T0 --stdout -d BforA-updates.archive.zstd | rsync --read-batch=- -a "${path_to_Alocalfiles}"。

インターネット接続が遅すぎると、状況が手動で処理される可能性があります。

職業だと思いますrdiff！ （基本的にはrsync別々の「ファイル署名の作成」、「デルタ計算」、「デルタによるパッチ」の段階に分かれています）

ローカルファイル（サーバーAなど）のチェックサムリストを生成します。その後、そのリストをサーバーBに送信することができます（またはオンラインでも膨大な量のデータではありません）。これらの署名を取得し、Bでファイルの他の部分を見つけて、これらの違いをポータブルSSDに保存します。 Aに戻って変更を適用できます。

だから私には次のようになります（テストされておらず、最初から最後まで書かれており、保証することはできませんが、役に立つことを願っています）！

署名を書く：

#!/usr/bin/zsh
## Signature tree storage script
## Goes through the current directory, writes a file signature for every file
## into an identically named file under $sigs,
## and creates an archive ~/signatures-(current datetime).squash in the home
## directory

sigs="/path/to/signatures"

# Let's assume we only sync regular files, not empty directories, nor sockets, nor symlinks, nor device nodes,…

for f in **/*(.) ; do
  # remove trailing path component, i.e. file name from $f and use that to
  # create directory under sigs prefix
  mkdir -p "${sigs}/${f:h}" 

  # write signature to file in prefix
  rdiff signature -- "${f}" "${sigs}/${f}"
done

# Assuming quite a few files are similar on a 1.4 TB thing, let's spend some
# time when archiving the signature prefix on minimizing the store needed for
# these.
# We use squashfs as archive format, as mksquashfs deduplicates, and allows us
# to compress on the fly – and also, because on the reading end, we can just
# mount the archive without unpacking it.
mksquashfs "${sigs}" "~/signatures-$(date -Is).squash" -comp zstd

受信側では反対の操作を行います。つまり、署名… .squashファイルをインストールし、ツリーをナビゲートし、rdiff delta -- ${signature_file} ${actual_file} deltas/${actual_file}デルタを作成します。$deltasカタログ全体を保管して家に持ち帰りますrdiff path -- ${actual_file} ${delta_file} updated/${actual_file}。

おすすめ記事