タグ

rsyncに関するissmのブックマーク (9)

  • scp で中断したファイル転送をrsync --partial option でレジューム - matoken’s meme -hatena-

    scp で大きなファイルを転送中にWifi が切れて途中で失敗してしまいました. wget -c みたいにファイル転送を途中からやり直せないかなと思って少し調べたらrsync に--partial というoption がるのに気づきました. 早速使ってみるとこんな感じでうまく行ったようです. % rsync -vvve ssh --partial localfile remoteserver:/path/file --snip-- generate_files finished Transferred: sent 27356560, received 327608 bytes, in 212.8 seconds Bytes per second: sent 128579.3, received 1539.8 sent 27263249 bytes received 314261 bytes

    scp で中断したファイル転送をrsync --partial option でレジューム - matoken’s meme -hatena-
    issm
    issm 2015/08/26
  • Linuxのブロックデバイスレベルで実現するrsyncより高速な差分バックアップについて - ゆううきブログ

    社内で論文輪読会みたいなことやってて、そこで紹介した論文の内容についてです。 最近、Graphite に保存しているデータのバックアップ(データ同期)に rsync 使ってて、かなり遅いので困ってた。 LISA っていう 大規模システム、sysadmin 系のカンファレンスがあって、ここから論文探してたら、ちょうど巨大データの高速バックアップの実装の話があったので読んでみた。 論文概要 dsync: Efficient Block-wise Synchronization of Multi-Gigabyte Binary Data - https://www.usenix.org/conference/lisa13/technical-sessions/presentation/knauth - Thomas Knauth and Christof Fetzer, Technische U

    Linuxのブロックデバイスレベルで実現するrsyncより高速な差分バックアップについて - ゆううきブログ
  • Rsync 3 を試す

    残念ながらCPU性能も変わっているのでこの数字を出しても比較にならないんだけど、さすがに10倍も性能向上はしていないので、それを差し引いてもやはり CPU 負荷は数分の一以下になっていると見て間違いないと思う。 今までは結構簡単に跳ね上がっていた CPU 使用率が、ほんとに rsync は動いているのか?と疑いたくなるくらいに大人しいまま。これはすごい。 –iconv での文字コード変換※ 文字コードなのかエンコーディングなのかというのはここでは問わないでください。

    issm
    issm 2012/05/31
  • Index of /ftp/rsync

  • rsync 3.0: uyota 匠の一手

    rsync がバージョン 3.0 を発表した。release NEWS を読むとかなりの量の変更がある。 その中で、真っ先に目に付いたのが、この機能強化。 - A new incremental-recursion algorithm is now used when rsync is talking to another 3.x version. This starts the transfer going more quickly (before all the files have been found), and requires much less memory. See the --recursive option in the manpage for some restrictions. 差分更新の時に、転送元と転送先を同時に走査し、すぐに差分の転送を始める。 以前のバージョ

    issm
    issm 2012/05/31
  • rsync - オプションなどの基礎

    1 Mar 1999 NAMErsync - rcp よりも速くて、柔軟性に富んでいます SYNOPSIS rsync [OPTION]... SRC [SRC]... [USER@]HOST:DEST rsync [OPTION]... [USER@]HOST:SRC DEST rsync [OPTION]... SRC [SRC]... DEST rsync [OPTION]... [USER@]HOST::SRC [DEST] rsync [OPTION]... SRC [SRC]... [USER@]HOST::DEST rsync [OPTION]... rsync://[USER@]HOST[:PORT]/SRC [DEST] 説明 rsync は rcp とほとんど同じ方法で動くプログラムですが、より多くの オプションを持っています。目的のファイルが既に存在する場合に、 rs

  • rsync -Rで中間ディレクトリがシンボリックリンクな場合の注意点 - (ひ)メモ

    複数サーバを管理する場合、管理コストの増加やオペレーションミスを避けるための施策として、「すべてのサーバの内容を同一に保つ」という管理方法があります。 サーバの内容を同一に保つには、小中規模ならrsyncと、パス指定の簡便化とミスを防ぐために-a -R (--relative)オプションを使うのがベストでしょう。 ただ、-Rを指定しているときに、同期コピー対象のパスにディレクトリへのシンボリックを含んでいる場合には注意が必要です。そこで今回はrsync 2.6とrsync 3のそれぞれについて、ふたつのケースについて検証してみたいと思います。 ケース1: 実ディレクトリが同じ 物理的なディレクトリ構造をそのまま見せるのではなく、論理的な意味あるディレクトリ名/構造として見せたい場合には、ディレクトリのシンボリックリンクを使うとよいです。 例えば: RAID等のストレージにあるディレクトリの

    rsync -Rで中間ディレクトリがシンボリックリンクな場合の注意点 - (ひ)メモ
  • rsync 3.0 - 酒日記 はてな支店

    rsync 3.0 がリリースされたそうです。 差分更新の時に、転送元と転送先を同時に走査し、すぐに差分の転送を始める。 rsync 3.0: uyota 匠の一手 という、素晴らしい機能強化が。 今までは rsync は一旦全ての転送元ファイルをチェックしていたので、巨大なディレクトリを rsync しようとするとかなり長時間待たされる。だけならまだしもメモリもがんがん喰う、という問題があった。会社のファイルサーバを丸ごと転送しようとしたら、rsync が out of memory で死んだことも……(仕方ないのでサブディレクトリ単位で実行したり) 実際に 3.0.0 をインストールして試してみたところ、ファイルが大量にあるディレクトリでもすぐに転送が始まって、メモリ使用量も全然増加せず。これは素晴らしい。 が、いきなり運用中のサーバで使うのは怖い (ただの印象) 気がするので、いく

    rsync 3.0 - 酒日記 はてな支店
  • 地雷だらけのrsyncを理解する。 - こせきの技術日記

    rsync -avz --exclude-from=pattern-file --delete SRC/ DEST SRCの末尾に/をつける。たいてい必要。 SRCスラッシュの有無は、mv SRC DEST と mv SRC/* DEST の違いと一緒。スラッシュの後ろに*が省略されているものと考える。 DESTのスラッシュの有無は関係なし。 --dry-run(-n)をつけて試す。 SRC、DESTともローカルのディレクトリを指定して試す。 DESTはまず空ディレクトリで試す。DESTが同期済みだと何が更新されるのか正確にわからないので。 --list-onlyをつけてファイル一覧を得る。 DESTを省略してファイル一覧を得る。 --list-onlyと同じ? --deleteはDESTのファイルを根こそぎ削除する可能性がある。注意。 --delete-excludedは使わない。--d

    地雷だらけのrsyncを理解する。 - こせきの技術日記
  • 1