
データが多い場所に行かなければなりません。どちらの場所もインターネット接続が遅かった。したがって、インターネットを介して2つの場所間でデータを同期することは不可能です。だからアイデアは、スニーカーネットワークを使用してデータを同期することです。
A場所にいるときは、NVMEドライブをサーバーに接続します。去るときは運転をします。 B位置にいるときは、ドライブを別のサーバーに接続します。
それでは、データを同期する最良の方法は何ですか?
sneakerssyncプロジェクトを見つけました。https://github.com/lamyj/sneakersync しかし、このプロジェクトにはいくつかの制限がないため、私には適していません。
- 当初、同期するデータは約45TBでした。しかし、NVMEの時間とスペースは限られています。
- 同期は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.zst
NVMeを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}
。