backupに関するoinumeのブックマーク (20)
-
oinume 2022/03/13
-
AWSのEBSボリュームのスナップショットを定期的に取る
AWSのEBSボリュームのスナップショットを定期的に取る 2015-10-19 小ネタだけど、久しぶりに技術的な内容の記事を書いてみる。最近はこういうのはQiitaに書くのが流行り？ EBSボリュームのスナップショット インスタンスストレージ(インスタンスに無料で付いてくるローカルストレージ)と比べてEBSを使うことの利点の一つに、スナップショットを取れるというのがある。これはもちろんAWSのコンソールからの操作でも、awscliのようなツールを使ってもできるんだけど、いちいちこれらの操作をやるのは面倒になってくる。そうすると、 自動で定期的にスナップショットを取りたい 古いスナップショットは自動的に消したい 複数のEBSボリュームのスナップショットをまとめて取りたい 全ボリュームのスナップショットを取る必要はなく、一部だけ取っておきたい みたいな話が出てくる。 そういう時にはもちろんaw
-
MySQLのバックアップ運用について色々
12. ステップ的なもの サイズ 使いどころ コマンド例 フルバックアップ でかい 必ず必要 tar, rsync, mysqldump, XtraBackup 差分バックアップ ⼩さい フルバックアップの 間隔が短ければ要ら ない mysqldump(スキー マに制約) XtraBackup 増分バックアップ 更新量に依存 ほぼ間違いなく必要 cp, rsync, mysqlbinlog 11/58 14. フルバックアップの選択肢 コマンド エンジン アプリ影響 ⽅式 サイズ tar, rsync MyISAM × 停⽌またはロッ ク 物理 ⼤きめ tar, rsync InnoDB × mysqld停⽌ 物理 ⼤きめ LVMスナップ ショット MyISAM InnoDB △ 性能劣化がひど い 物理 ⼤きめ mysqldump MyISAM × ロック 論理 ⼩さめ mysqldum
-
-
MySQL バイナリログを使ったデータリカバリ | Ore no homepage
目黒川の桜きれいですね〜(*^^*)…なーんてガラじゃないことを言いたくなるくらい良い咲きっぷりでしたよ、エエ。で、来週末、花見に行くんだけど、まだ散らないでほしいっすねー。 えーっと、久しぶりにMySQLの記事。binlogを使ったリストア手法について。ネットを漁るとMySQLの運用に関する記事は多くヒットするんだけど、障害からのデータリカバリ、特にロールフォワードを扱った記事が思ったより多くない。おれは運が良いのか悪いのかMySQLのデータリカバリをしなければならないような局面に何度か直面しているので、手順について書いてみようかな、と。ここではMySQL〜5.5を対象にしている。直近での最新のメジャーバージョンはMySQL5.6なんだけど、おれはまだ5.6について大して知らない。5.6ならもっとイケてるやりかたがあるかもしれない。あったらいいな。 0. 環境 次のような環境を前提として
-
Bakthat: Python backup framework and command line tool — Bakthat 0.4.0 documentation
Bakthat: Python backup framework and command line tool¶ Release v0.4.0. Bakthat is a MIT licensed backup framework written in Python, it’s both a command line tool and a Python module that helps you manage backups on Amazon S3/Glacier. It automatically compress, encrypt (symmetric encryption) and upload your files. Here are some features: Compress with tarfile Encrypt with beefish (optional) Uploa
-
redisのバックアップは慎重に | Nekoya press
皆様におかれましては、WEB+DB PRESSの最新号のRedis特集は既にご覧頂いたかと存じます。 弊社では1年ほど前から広告配信に関する様々な部分でRedisを使っています。まだ2.4系なので、2.6の新機能とか新鮮でした。 本番環境でRedisを運用する上で、強く訴えたい注意点は「RDBが壊れることがある」ということです。 「RDBがあるからインスタンスが落ちても平気だぜ」とか思ってると、RDBが壊れてリストア失敗→データ消失ということになりかねません。ファイルにdumpされるからと安心していると痛い目に遭うかも知れません。 （2013/02/27追記）今のところ壊れたのはハード障害が怪しい場面のみです。「RDB壊れるとかRedis使えねー」とかそういう話ではまったくありません。誤解無きよう。壊れる時はRedisじゃなくても壊れます。自分のユースケースではTokyo Cabinet/
-
Percona XtraBackupの抽出と圧縮の並列処理 | 外道父の匠
久々にXtraBackupの話題です。 以前に紹介した基本手順では、tarアーカイブをgzip圧縮していました。 実はこれよりもっと速い方法がありまして、データサイズが大きくなると必須になってくるのではないかと思います。その、計測内容と結果について紹介していきたいと思います。 リンク 本件に関係ありそうなドキュメントのリンクになります。 The xtrabackup Option Reference Streaming and Compressing Backups The xbstream Binary Accelerating with –parallel copy and –compress-threads Making a Compressed Backup (qpress) 本家ブログのベンチマークもあります。 Compression for InnoDB backup – My
-
git のバックアップ - Hatak::Techlog
分散 SCM とはいえ、バックアップはあるとうれしいものです。git のリモートリポジトリが破損した場合などに復元元を探すために、誰が持っているのが最新のリビジョンで、、というような作業が発生することは避けたいからです。 git のリモートリポジトリから別のサーバにバックアップを作成するのは、hooks を利用することで簡単に設定できます。例えば、対象となるリポジトリの post-receive で下記のようなコマンドを設定しておくとできます。 バックアップ先のサーバ:ディレクトリは targethost.example.jp:/var/lib/git バックアップのための SSH 接続で利用するユーザは syncuser gitosis ユーザは syncuser 権限で git コマンドが利用出来るように visudo を設定 #!/bin/sh ##### # hooks/post-
-
Pro-tip: How To Backup All Of Your GitHub Repositories In One Go
Pro-tip: How To Backup All Of Your GitHub Repositories In One Go March 27, 2012 Today, I’m going to present solutions for easily backing up all of your GitHub repositories in just a step or two. Minimal knowledge of GitHub fundamentals are assumed but if you have experience with writing in Ruby that'll be a plus. This won't however hinder your ability to get the most out of this post, so let's get
-
MySQLバックアップツール比較 XtraBackup / mysqldump / Mydumper | さぶみっと！JAPAN
総合的なスピードを見ると、リストアでXtraBackupがかなりの差をつけました。 Mydumperはスレッド数4で試しましたが、CPUコア数の多いサーバでスレッド数を上げたらもっとよい結果になりそうです。 以下、テストデータの準備とそれぞれツールのインストール方法を記述しています。 参考になれば幸いです。 使用したサーバ サーバ さくらのクラウド プラン7-HC CPU仮想5コア メモリ12GB HDD250GB OS CentOS 5.7 64bit MySQL 5.5のインストール remiレポジトリから検証用のMySQLをyumからインストールします。 # rpm -Uvh http://rpms.famillecollet.com/enterprise/remi-release-5.rpm # yum --enablerepo=remi install mysql.x86_64
-
rdiff-backup: Main Page
_// Reverse differential backup tool, over a network or locally Rdiff-backup backs up one directory to another, possibly over a network. The target directory ends up a copy of the source directory, but extra reverse diffs are stored in a special subdirectory of that target directory, so you can still recover files lost some time ago. The idea is to combine the best features of a mirror and an incr
-
いますぐ実践! Linuxシステム管理
「いますぐ実践! Linux システム管理」はこちらです。 メルマガの解除、バックナンバーなども、以下からどうぞ。 https://www.usupi.org/sysad/ (まぐまぐ ID:149633) その他、作者に関するページは、概ね以下にございます。 https://www.usupi.org/kuri/ (まぐまぐ ID:126454) http://usupi.seesaa.net/ (栗日記ブログ) https://twitter.com/kuriking/ (twitter) https://facebook.com/kuriking3 (facebook) https://jp.pinterest.com/kuriking/pinterest) https://www.instagram.com/kuri_king_/ (instagram) [バックナンバーのトップへ
-
-
MySQL :: MySQL 5.1 リファレンスマニュアル :: 4.9.1 データベースのバックアップ
MySQL テーブルはファイルとして保存するため、バックアップを簡単に行えます。整合性のあるバックアップを行うには、関連するテーブルで LOCK TABLES を行い、そのテーブルを FLUSH TABLES します。(項12.4.5. 「LOCK TABLES と UNLOCK TABLES 構文」 と 項12.5.5.2. 「FLUSH 構文」 を参照のこと。) 読み込みロックだけを行うため、データベース ディレクトリのファイル コピーを行う一方で、別のクライアントはテーブル照会を続けることができます。ここで、FLUSH TABLES ステートメントを必要とする理由は、バックアップを開始する前に、アクティブのインデックス ページすべてのディスクへの書き込みを確実に行うためです。 テーブルを SQL レベルでバックアップするには、SELECT INTO ... OUTFILE を使用しま
-
Kazuho@Cybozu Labs: blockdiff を使ったお手軽ホットバックアップ環境の構築 (Linux, MySQL, etc.)
一昨日に開催された hbstudy #7 にバックアップの話を聞きに行ってきました。Amanda を中心にした話で、とても勉強になりました。が、設定がめんどくさそうだなぁ、とも。自分の需要にはあわない感じでした。 勉強会が終わったあとで、自作のバックアップスクリプト blockdiff に関する話を何人かの方とさせていただいたのですが、思いのほか反応が良かったので、あらためて紹介したいと思います。 blockdiff は、一言でいうと、パーティションやデータベースのデータファイルの差分バックアップツールです。rsnapshot に似ていますが、rsnapshot ではデータベースのホットバックアップ不可能です。逆に blockdiff はディレクトリ単位でのバックアップには対応していないかわり、ファイルシステムやデータベースを、一貫性を保ちつつ実質無停止で差分バックアップすることができます
-
LsyncdRsyncTargetDirectory - mizzy.org - Trac
lsyncd が rsync する対象ディレクトリを調べてみた inotify + makuosan でいい感じのリアルタイムミラーリング で、lsyncd は結局は rsync を裏で呼び出してるので、差分チェックの呪縛からは逃れられない、的なことを書いてたんですが、ふと、「もしかして、inotify から rsyncを呼び出すときに、同期対象となるファイルは、指定したディレクトリ以下のもの全部ではなく、変更があったファイルがあるディレクト以下のものだけ、なんて動きをしてくれるのかな？」と気になったので、実際に試してみました。結果から先に言うと、想定通りの動きとなってます。これって常識なんですかね？以下、試した時のログ。 ログを確認するために、lsyncd をフォアグランドで起動。 $ ./lsyncd --no-daemon /tmp/lsyncd localhost:/var/tmp
-
MySQL :: MySQL 8.0 リファレンスマニュアル :: 7.3 バックアップおよびリカバリ戦略の例
このセクションでは、いくつかの種類のクラッシュ後にデータをリカバリできるようにするバックアップを実行するための手順について説明します。 コマンド例には、mysqldump および mysql クライアントプログラム用の --user や --password などのオプションは含まれていません。 クライアントプログラムが MySQL サーバーに接続できるようにする必要に応じて、それらのオプションを含めてください。 データは、トランザクションと自動クラッシュリカバリをサポートする InnoDB ストレージエンジンに格納されているとします。 さらに、MySQL サーバーはクラッシュ時に負荷がかかっているとします。 そうでなければ、リカバリは必要ないことがあります。 オペレーティングシステムのクラッシュや停電の場合、再起動後、MySQL のディスクデータを使用できるものと考えることができます。
-
Percona XtraBackup: Open Source Alternative for InnoDB Hot Backup call for ideas
All of Percona’s open-source software products, in one place, to download as much or as little as you need.
-
Backup MySQL Databases | MySQL Backup & Restore | Zmanda
Workloads Virtual Systems VMware vSphere | Microsoft Hyper-V Server Instances Linux | Windows | Mac Endpoints (OS) Linux | Windows | Mac Applications Active Directory | MS Exchange | MS Sharepoint | Microsoft 365 File SystemsCIFS | NFS/ISCSI/Lustre | ZFS DatabasesMariaDB | MySQL | MSSQL | MongoDB StorageAWS cloud storage | Local disk | Tape libraries View full compatibility matrix
-
1
公式Twitter
- @HatenaBookmark
リリース、障害情報などのサービスのお知らせ
- @hatebu
最新の人気エントリーの配信
キーボードショートカット一覧
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
