タグ付けされた質問 「snapshot」

スナップショットは、特定の時点で取得されたデータのコピーです。

2
スナップショットの進行中にAmazon EBSボリュームを使用しても安全ですか?
スナップショットの作成中にEBSボリュームを使用しても安全ですか? 現在、100Gb EBSボリュームをマウントしています。現在スナップショットを作成中です。良さは遅い!! スナップショットに45分以上かかることになります。 私の質問:EBSボリュームはすでにコピーされており、どこかに保存されていますか?または、現在、スナップショットはマウントされたボリュームからアクティブにコピーしていますか? 基本的に、スナップショットが完了する前に使用を開始した場合、ホースは使用されますか? コピーに時間がかかるとは信じられません。使用中の100GBでさえありません。25Gbのようなものです。

4
LVMスナップショットとファイルシステムスナップショット
私の知る限り、LVMはボリュームのスナップショットを取ることを可能にします。スナップショットをサポートする多くのファイルシステム(ZFS、Btrfs、reiserfsなど)もあります。 ただし、LVMスナップショットとファイルシステムスナップショットの違いを理解したことはありません。LVMでスナップショットを取得できる場合、なぜ誰かがそれをファイルシステムに実装するのに時間をかけるのですか? 編集:いくつかの状況でそれらのいずれかが好まれていますか?どうして?
32 lvm  zfs  snapshot  btrfs 

4
VMスナップショットがパフォーマンスに影響するのはなぜですか?
VMware KBの記事の1つで、スナップショットがVMのパフォーマンスに直接影響することを読みました。 しかし、私のチームは、スナップショットがパフォーマンスにどのように影響するかを尋ね続けています。 私は、スナップショットがパフォーマンスキラーであるという声明の背後にある確固たる理由を伝えたいと思います。 スナップショットが実際にパフォーマンスにどのように影響するかについて、誰でも少し理論を説明できますか?ハードディスクのディスクI / Oレートが遅いという理由だけですか?

6
スナップショットが実際のバックアップではなく一時バックアップと見なされるのはなぜですか?
VMware ESXiを使用しています。私たちのチームでは、長期バックアップ用のスナップショットを提供しています。 その後、メモリのスピルオーバーなどの問題に直面し、サーバーがハングアップしました。 私はVMwareナレッジベースの記事をどこからでも読み始めました。どこでも、スナップショットを長時間保持しないことが推奨されました。 VMwareでさえ、スナップショットを最大3日間保存することを推奨しました。 しかし、私たちのチームは、少なくとも2つの永続的なスナップショットを(VMを削除するまで)保持するように要求し続けました。VMを1年間使用することもあります)。 1つのスナップショットは、新しいマシンの状態用です。(したがって、アプリケーションのテストが完了すると、新しい状態に戻り、別のアプリケーションをインストールします)(許可しない場合は、VMをホストする必要がある場合があります。) VMを特定の状態に保つための次のスナップショット(問題を発見してしばらくその状態を維持する可能性があります。または、アプリケーションの前提条件をインストールし、マシンをテストの準備ができている場合があります) 論理的には、彼らのニーズは公平なようです。しかし、それを許せば、スナップショットを長時間保持することを許可することになります。VMをメールサーバーまたはデータベースサーバーとして使用していません。 スナップショットを長時間保持すると悪影響があるのはなぜですか? スナップショットが実際のバックアップではなく一時的なバックアップと見なされるのはなぜですか?

6
最後の[n] ZFSスナップショットを除くすべてを削除する方法は?
現在、毎晩ZFSベースのNASのスナップショットを撮っています。これにより、数回、お尻が救われました。ただし、スナップショットの作成は(cronから)自動で行われますが、古いスナップショットの削除は依然として手動のタスクです。明らかに、バスに衝突したり、手動タスクが実行されなかったりすると、NASのディスク容量が不足するリスクがあります。 ZFSシステムに保存されているスナップショットの数を管理するために使用する良い方法/スクリプトはありますか?理想的には、特定のZFSファイルシステムのすべてのスナップショットを反復処理し、そのファイルシステムの最後のn個を除くすべてのスナップショットを削除するスクリプトが必要です。 たとえば、2つのファイルシステムがあります。1つはを呼び出しtank、もう1つはを呼び出しsastankます。スナップショットには、作成された日付の名前が付けられます。sastank@AutoD-2011-12-13したがって、簡単なsortコマンドでスナップショットを順番にリストする必要があります。過去2週間分の毎日のスナップショットをオンtankにしたいのですが、最後の2日間分のスナップショットのみをオンにしsastankます。
24 solaris  zfs  snapshot 

3
3日以上のVMwareスナップショット
この記事を参照 https://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1025279 パフォーマンスが低下する可能性があるため、スナップショットを1日または2日より長く保持することはお勧めできません。 チェーンが4または5を超えることはほとんどありません ただし、実稼働環境にプッシュする前に、ベンダーによるテストが必要なアプリケーションがいくつかあります。 ほとんどの場合、スナップショットを取得してから数日以内に取得してテストすることができますが、1週間以上かかる人もいます。 アプリケーションが機能せず、以前のアプリケーションに戻さなければならず、スナップショットがすでに削除されています。 ボックスはかなり忙しく、ロギング、メールなどです。 他の組織はこれにどのように対処しますか?スナップショットを「バックアップ」する方法はありますか?

8
スナップショットとRAIDは、オンサイトの優れたバックアップソリューションとしてカウントされますか?
バックアップを取る理由として考えられる2つの主な理由は、スナップショットとRAIDの両方をbtrfsと共に使用する場合に注意が必要と思われます。(ここでRAIDとは、RAID1または10を意味します) データの偶発的な削除:スナップショットはこのケースをカバーします ドライブの故障とビットの腐敗 完全な障害:RAIDはこのケースをカバーします 不良データを返すドライブ:RAID + btrfsのエラー修正機能がこのケースをカバー オンサイトのバックアップソリューションとしては、これはうまく機能しているようで、別のデータストレージデバイスは必要ありません! ただし、RAIDとスナップショットの両方が適切なバックアップとは見なされないと聞いているので、何か見落としているのではないかと思っています。 btrfsがまだ成熟した技術ではないことを除けば、私が見落としたことはありますか?または、私の考えは正しいですか、これは有効なオンサイトバックアップソリューションですか?

4
これはLVMスナップショットの仕組みですか?
私はファイルサーバーにLVMスナップショットを実装できるようにLVMスナップショットがどのように機能するかを理解しようとしていますが、ベースバックアップシステムに使用する方法ではなく、それがどのように機能するかを説明するものをGoogleで見つけるのが困難です。 私が読んだことから、私はそれが次のように働くと思う: プライマリパーティションと、パーティションにない多くの未割り当ての空き領域を持つLVMがある 次に、スナップショットを作成して、新しい論理ボリュームにマウントします。スナップショットには変更があるはずなので、この最初のスナップショットは完全なコピーになりますよね? 次に、翌日、別のスナップショットを作成し(このスナップショットのパーティションサイズはそれほど大きくする必要はありません)、それをマウントします。 どういうわけか、LVMはスナップショットを追跡し、変更されていないビットをプライマリボリュームに保存しません。 次に、十分なスナップショットがあると判断し、最初のスナップショットを削除します。これがどのように機能するか、またはそれが次のスナップショットにどのように影響するかはわかりません。 誰かが私が間違っている場所を私に修正できますか?せいぜい、私はグーグルで何も見つけられないと推測しています。 vgdiplay obu1:/ home / jail / home / qps / backup / D#vgdisplay ---ボリュームグループ--- VG名fileserverLVM システムID フォーマットlvm2 メタデータ領域1 メタデータシーケンスNo 3 VG Access読み取り/書き込み VGステータスのサイズ変更可能 最大LV 0 Cur LV 2 LV 2を開く 最大PV 0 Cur PV 1 Act PV 1 VGサイズ931.51 GB PEサイズ4.00 MB …
19 linux  lvm  snapshot 

3
VMWareスナップショットで永続的に実行するとパフォーマンスが低下しますか?
VMWare KBは、主に2つのことが原因で、長時間実行されるスナップショットで眉をひそめることを理解しています(私の意見では) 大量のスナップショットを作成すると、データストアがいっぱいになる可能性があります。スナップショットは単なるデルタファイルです。50 Gig VMDKがほぼ一杯になっていて、スナップショットを撮るとします。スナップショットでは、すべてのビットを反転します。デルタファイルも約50 GBです。スナップショットを再度作成し、ビットを反転させて、別の50 Gigデルタファイルを作成します。これらは制御不能になることがあります。 大きなスナップショットのコミットにはリスクが伴います。スナップショットを統合する場合、元のVMDKにデルタ変更を書き込みます。これには時間がかかり、何か問題が発生した場合、VMDKを削除するだけのリスクが伴います。 彼らの警告は理にかなっているようだ。 そうは言っても、スナップショットVMDKからマシンを永続的に実行することは本質的に悪いことですか?私は私のツリーを次のようにします: ベース Snap1 スナップ2 あなたはここにいる スナップ1と2は、ベースシステムのインストールとプロビジョニングの直後に取得されます。これらは頻繁に更新する予定のマシンなので、単純にツリーを次のようにします。 ベース Snap1 あなたはここにいる スナップ2 Snap2を削除して、Snap2を再作成します。 次の理由により、これがどのように影響するかはわかりません。 単にベースイメージをインストールし、データストアがいっぱいになる可能性がなくなった直後にデルタを取得したためです。ベースイメージが10 GB(50 GBのシンプロビジョニングされたディスク上)であると仮定すると、デルタがすべてのシングルビットをフリップしても、最大合計使用量は60 GB(ロックされている10 GBベースVMDK + 50 GBのデルタ+スナップショットVMDKファイル)。これは、これ以上スナップショットを作成しないことを前提としています。 私のユースケースではスナップショットの統合を要求していないため、デルタを統合する際にエラーが発生するリスクはありません。Snap1に戻ってSnap2を削除すると、Snap2に存在していたすべてのデルタが単純に削除されます。 ストレージの負荷はまったく同じなので、同じIOPSを取得する必要があります。一部のファイル(主にシステムファイル)が元のVMDKに存在し、他のファイル(ベースの後のすべて)がデルタに存在することを理解していますが、ESXIがどのように気にするかわかりません。すべてのファイルは同じ物理データストアにあるため、スナップショットなしで元のVMDK内のすべてを参照するのと同等のパフォーマンスが必要です。 何かご意見は?データストアがRAID'd DASであるESXI 5.5。 vCenterライセンスがないので、テンプレートとクローン作成はできません。 テスト結果 今日は早くテストに参加しました。結果は次のとおりです。パフォーマンスが低下しますが、理由はわかりません。 スナップショットの前: スナップショット後:

6
Linux LVMスナップショットをコミットまたは復帰しますか?
CentOS 5サーバーで実験的なアップグレードを実行しようとしています。アップグレードが失敗した場合、ファイルシステムへの変更をバックアウトできるようにしたいと思います。このシナリオは、LVM2読み取り/書き込みスナップショットのLVM HOWTOのセクション3.8の例に似ていますが、実際のハウツーには例がありません。 変更をコミットして元のパーティションにマージする方法は? ファイルシステムを元の状態に復元して、変更を元に戻すにはどうすればよいですか?完全に再起動しない場合、いくつかのサービスを再起動する必要があると仮定する必要がありますか? パーティション上の特定のディレクトリのみをスナップショットすることは可能ですか、それともパーティション全体の操作ですか?
16 linux  lvm  snapshot 

13
ZFS send / recvに最適な圧縮
ポイントツーポイントT1回線を介して増分ZFSスナップショットを送信していますが、次のバックアップが開始される前に、1日分のスナップショットをネットワーク上で作成することはできません。send / recvコマンドは次のとおりです。 zfs send -i tank/vm@2009-10-10 tank/vm@2009-10-12 | bzip2 -c | \ ssh offsite-backup "bzcat | zfs recv -F tank/vm" 予備のCPUサイクルがたくさんあります。より少ないデータを回線にプッシュするために使用できる、より良い圧縮アルゴリズムまたは代替方法はありますか?

4
LVMスナップショットを保持またはドロップする方法
LVMスナップショップを作成しました lvcreate --name snap --size 10G -s /dev/vg00/vm スナップショットを削除し、スナップショット以降に発生した変更を保持しない場合、どのコマンドを記述する必要がありますか? そして、スナップショットからの変更を/ dev / vg00 / vmにロールするには、どのコマンドを書くべきですか?
14 linux  lvm  snapshot 

1
スナップショットの削除が非常に遅い
iSCSI経由で公開されたHP LeftHandストレージを備えたESXiボックスがあります。 1TBのディスクを持つ仮想マシンがあり、そのうち800GBが消費されています。ディスクは、LeftHandストレージにシックプロビジョニングされています。 VMでスナップショットが開かれ(Veeam Backup and Recoveryが処理できるように)、約6時間開かれました。この間に約5GBのデルタディスクが作成されました。 スナップショットの削除には5時間以上かかりましたが、まだ完了していません。ストレージアレイは、そのアレイで実質的にIOPS(バックグラウンドノイズである約600)、スループットなし(バックグラウンドノイズである約8MB /秒)、平均キュー深度9を実質的に報告しています。 言い換えれば、スナップショット統合プロセスはIOバウンドではないようです。スナップショットの削除が非常に遅くなる原因は何もわかりません。それはされて差分ファイルを見て判断し、取り組んでいます。 この(比較的小さい)スナップショットを削除するのが非常に遅い理由について、他に検討すべきことはありますか? あたりとしてVMwareのマニュアル、私は見ているls -lh | grep -E "delta|flat|sesparse"今、私は変更されている2つの差分ファイルを参照してください。 -rw------- 1 root root 194.0M Jun 15 01:28 EXAMPLE-000001-delta.vmdk -rw------- 1 root root 274.0M Jun 15 01:27 EXAMPLE-000002-delta.vmdk あるスナップショットファイルが統合され、他のスナップショットファイルは統合プロセス中にデルタを収集していると推測しています。次に、新しいものが統合され、そのプロセス中に別のデルタが作成されます。 ファイルサイズは各反復(まあ、ほとんどの反復)で低下しているので、最終的にこの統合手順が完了すると思います(変更を生成せずにこれを完了するには、30分間VMをネットワークから取り外す必要があるかもしれません) 。 統合するには、デルタ100メガにつき約2分かかります。これは確かに前に起こったことはありません。通常のVeeamバックアップでのスナップショットの削除には約40分かかります(確かに高速ではありませんが、この速度ではありません)。 6時間2分後に、スナップショットは最終的に削除されます。ただし、この種の問題(ストレージのパフォーマンス以外)を通常トラブルシューティングする方法があるかどうかを引き続き知りたいと思います。

2
VMwareでスナップショットを削除すると、子供はどうなりますか?
私は仮想化に慣れていないので、スナップショットを削除するとどうなるかを理解したい このような木があるとしましょう ベース スナップショットA スナップショットB スナップショットC 2つの質問: SnapShotBを削除すると、SnapShotCに何が起こりますか? VMwareのヘルプから「注:[削除]をクリックすると、スナップショットデータが親にコミットされ、選択したスナップショットが削除されます。 " SnapShotA?

3
Windowsでファイルシステム/レジストリスナップショットを作成/比較する方法は?
Windows(XP、Vista、または7)プログラムインストーラーによってインストール/変更されたすべてのファイルと追加/削除されたキーのリストを取得する簡単な方法は何ですか? 前と後のスナップショットを撮り、何が変わったのかを確認したいと思います。インストールの実行中にプログラムを実行したままにしておいても大丈夫です。 これはClinton Blackmoreの質問(例:2つのファイルシステムの取得と比較)に非常に似ていますが、特にWindowsで、ファイルとレジストリキーの両方を考慮しています。

弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.