バックアップサーバーの構成。 Linux、ZFSおよびrsync

TL; DR：

バックアップLinuxサーバーの構成に関する記事。 ストレージとして、ZFSパーティションは重複排除と圧縮を有効にして使用されます。 スナップショットは毎日作成され、1週間（7個）保管されます。 毎月のスナップショットは年間を通じて保存されます（さらに12個）。 Rsyncはトランスポートとして機能します。サーバーではデーモンによって起動され、クライアントではcrontabから起動されます。



そのため、仮想マシンがKVMの下に存在するサーバーがいくつかあることがありました。 これらのマシンのイメージをネットワークにバックアップしたかったのですが、条件が満たされました。

• 先週のすべてのバックアップを保持します。
• 年間を通じて毎月のバックアップを保持します。
• サードパーティのバックアップエージェントはありません。 クライアント上でのみ標準であり、ソフトウェア管理者の世代によってテストされています。
• ストレージのスペースを節約します。 圧縮とデータ重複排除が望ましい。
• すべてのファイルは、追加のツールやシェルなしでアクセスできる必要があります。 理想的なオプション：個別のディレクトリ内の各バックアップ。

これをすべて組み合わせることができますか？ はい、非常に簡単です。



この記事のすべてのコンピューターはサーバーです。 しかし、それらを「バックアップを保存するサーバー」と「バックアップを保存するサーバーによってバックアップが保存されるサーバー」に分けるのは、一種のばかげた長いことです。 したがって、最初は単純にサーバーを呼び出し、2番目は既にクライアントを呼び出し始めています。

1.圧縮と重複排除を使用したZFS

私にとって最も馴染みのあるOSはLinuxです。 すべて同じで、変更なしで、SolarisとFreeBSDの両方に適用する必要があります。ZFSは長い間使用されており、すぐに使用できます。 しかし、Linuxは私にとってより親密であり、 ZFSを Linux に移植するプロジェクトはすでにかなり成熟しているように見えます。 1年間の実験では、彼との間に目立った問題はありませんでした。 そのため、Debian Wheezyをサーバーにインストールし、公式プロジェクトリポジトリに接続して、必要なパッケージをインストールしました 。



/ dev / md1にzfsがあり、このファイルシステムを/ mnt / backupディレクトリにマウントすることを示すプールを作成しました。

# zpool create backup -m /mnt/backup /dev/md1
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

デバイスの名前/ dev / md1により、Linuxソフトウェアraidを使用していることがわかります。 はい、ZFSにはミラーを作成する独自の方法があることを知っています。 ただし、このマシンにはすでに1つのミラー（ルートパーティション用）があり、通常のmdadmによって作成されているため、2番目のミラーにも同様に使用することをお勧めします。



重複排除と圧縮が含まれ、スナップショットを含むディレクトリが表示されました：

 # zfs set dedup=on backup # zfs set compression=on backup # zfs set snapdir=visible backup
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

スナップショットを作成するためのスクリプトを/ usr / local / binに配置します。

 #!/bin/bash export LANG=C ZPOOL='backup' #    7  #         NOWDATE=`date +20%g-%m-%d` #   -- OLDDAY=`date -d -7days +%e` if [ $OLDDAY -eq '4' ] then OLDDATE=`date -d -1year-7days +20%g-%m-%d` #   -1   7  else OLDDATE=`date -d -7days +20%g-%m-%d` #   -7  fi /sbin/zfs snapshot $ZPOOL@$NOWDATE /sbin/zfs destroy $ZPOOL@$OLDDATE 2>/dev/null
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

このスクリプトは、毎日の起動のためにcrontabに追加されました。 スナップショットの内容をその日付に対応させるには、一日の終わり近くにスクリプトを実行することをお勧めします。 たとえば、23：55に。



月の4日目はほぼ偶然に選択されます。 8月3日にすべてを開始し、すぐにバックアップしたかったため、1年間保存されます。 翌日は4日目でした。



スナップショットは/mnt/backup/.zfs/snapshotディレクトリに保存されます。 各スナップショットは、このスナップショットが作成された日付の形式の名前を持つ個別のディレクトリです。 スナップショット内には、/ mnt / backupディレクトリの完全なコピーがその時点の形式で保存されています。

2.サーバー上のRsync

従来、rsyncはsshの上で動作するように設定されていました。 クライアントでは、キーによる（およびパスワードなしの）認証が構成され、これらのキーがバックアップサーバーに追加されます。 サーバーはsshを介してクライアントにアクセスし、クライアントからファイルを取得します。 このアプローチの利点は、トラフィックの暗号化です。 しかし、（特にbashの最新の脆弱性に照らして）sshを介したパスワードなしのログインのアイデアは好きではありません。 また、サーバー側からバックアップを開始するという考え方が好きではありません。クライアントでバックアップする前に、何らかのスクリプト（たとえば、mysqlダンプをダンプする）を実行したい場合があります。 したがって、私の選択はrsyncであり、サーバー上のデーモンによって起動され、クライアント上のcrontabから起動されます。



rsyncをサーバー（通常、リポジトリから）にインストールし、システムの起動時に起動するように、/ etc / default / rsyncに書き込みました。

 RSYNC_ENABLE=true
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

サーバー/etc/rsyncd.confに以下を作成しました。

 uid = nobody gid = nogroup use chroot = yes max connections = 10 pid file = /var/run/rsyncd.pid [kvm01] path = /mnt/backup/kvm01 comment = KVM01 backups hosts allow = 192.168.xxx.xxx hosts deny = * read only = no [kvm02] path = /mnt/backup/kvm02 comment = KVM02 backups hosts allow = 192.168.xxx.yyy hosts deny = * read only = no
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

192.168.xxx.xxxおよび192.168.xxx.yyyは、バックアップされるサーバーのアドレスです。 それらの名前はkvm01とkvm02です。 それらのファイルは、/ mnt / backup / kvm01および/ mnt / backup / kvm02にあります。 したがって：

 # mkdir /mnt/backup/kvm01 # mkdir /mnt/backup/kvm02 # chown nobody:nogroup /mnt/backup/kvm01 # chown nobody:nogroup /mnt/backup/kvm02
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

rsyncを起動しました：

 # /etc/init.d/rsync start
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

3.クライアントのRsync

kvm02クライアントからアドレス192.168.xxx.zzzのサーバーにファイルをコピーするために最低限必要なスクリプトは次のようになります。

 #!/bin/bash RSYNCBACKUPDIR="rsync://192.168.xxx.zzz/kvm02" LOCALDIR="/virt/files" rsync -vrlptD --delete $LOCALDIR $RSYNCBACKUPDIR
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

もちろん、仮想マシンのバックアップについて話している場合、このスクリプトには、LVMスナップショットの作成と削除、そのコンテンツのマウントとマウント解除などのコマンドを補充する必要があります。 しかし、このトピックはすでにこの記事の範囲外です。

4.リカバリー

2014年8月4日にKVM01クライアントのバックアップからファイルを復元するには、サーバー上で/mnt/backup/.zfs/snapshot/2014-08-04/kvm01/ディレクトリに移動し、そこから通常の方法でファイルをコピーするだけで十分です。 特定の各バックアップは、通常の読み取り専用ディレクトリのように見えます。 このバックアップで特定のファイルを検索するには、findやgrepなどの標準ユーティリティを使用できます。

5.結論

これで、サーバーには9つのスナップショットがあります：毎日7つと毎月2つ。 さらに、今日のバックアップ（夕方に削除されるスナップショット）。 バックアップを含むパーティションのサイズは1.8Tです。 合計ファイルサイズは3.06Tです。 それらはディスク上で318Gによって物理的に占有されています。 今日のバックアップの総量は319Gです。 はい、圧縮と重複排除を使用したZFSでの10個のバックアップは、これらの有用なプロパティのないファイルシステムでの1つのバックアップよりも少ないスペースを占有します。

 # zpool list NAME SIZE ALLOC FREE CAP DEDUP HEALTH ALTROOT backup 1.80T 310G 1.49T 16% 10.37x ONLINE -
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

 # zfs list NAME USED AVAIL REFER MOUNTPOINT backup 3.06T 1.42T 318G /mnt/backup
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

rsync自体は送信データの暗号化に関与しないため、インターネットを変更せずにこのようなスキームをインストールすることは安全ではありません。 たとえば、ipsecまたはstunnelを介してトラフィックを許可することにより、暗号化を追加できます。



ZFSには目立った問題はなかったと上に書きました。 実際、1つの問題がありました。 ある夜、両方のクライアントがアクティブにバックアップしていたとき、サーバーはdmesgにタスクrsyncが120秒以上ブロックしたことを2回通知しました。 同時に、両方のバックアップが正常に完了し、何もハングせず、データは失われませんでした。 これは有名なバグ12309の現れだと思います。 問題が再発していないので、時間内にバックアップを広げてください。