Blackblaze - オンライン・バックアップUnleash innovation, unburden teams, and unlock budgets with S3-compatible cloud storage at 1/5th the cost.
oinume journal
Next.js + Auth0で認証機能を実装しようとして、nextjs-auth0をセットアップしつつ、このドキュメント通りにやっていたら、AUTH0_ISSUER_BASE_URL の設定を間違えていて以下のエラーが出ていた。 LoginHandlerError: Login handler failed. CAUSE: Discovery requests failing for http://localhost:3000, expected 200 OK, got: 404 Not Found 上のauth0のドキュメントでは AUTH0_ISSUER_BASE_URL='https://{yourDomain}' との記述だったので、http://localhost:3000を指定したのだけど、どうやらこれはhttps://YOUR_AUTH0_DOMAIN.auth0.comを
「ニフティrクラウドユーザーブログ」は、移転しました。
「ニフティクラウドユーザーブログ」は、移転しました。 自動でページを移動しない場合は、下記のリンクをクリックし、 新しい「ニフティクラウドユーザーブログ」をご覧ください。 今後とも「ニフティクラウドユーザーブログ」をよろしくお願いいたします。 ＞ ニフティクラウドユーザーブログ
EC2インスタンスをS3にバックアップ＆AMIを作成 | 俺のメモ
順調に動いてる俺々LAMP環境のAMIを作成したい時の方法です。 EC2にS3にバックアップ用のコマンドが用意されてるのでそれを使います。 イメージを作成→S３に保存→AMIを登録といった流れになります。 まずは、AWSの管理画面で発行されたPrivate Key File(pk-*******************.pem)とX.509 certificate file(cert-*******************.pem)をローカルから俺々LAMP環境に送る。 scp -i oreore.pem *.pem root@ec2-**-**-**-**.compute-1.amazonaws.com:/mnt ローカルでの作業はこれだけで、以下、EC2の俺々LAMP環境の/mntでの作業。 ec2-bundle-vol -d /mnt --privatekey pk-********
EC2 での AMI 作成手順 - hyoromoのブログ
前々回は、インスタンスの起動・停止・確認まで進みました。そして、今回は AMI の作成を行いたいます。 作成理由は、EC2 をシャットダウンするとディスクに保存した内容が失われてしまうのですが。AMI を作成することにより、作成した時点のディスク内容でインススタンス起動できます。*1 今回も CodeZine に沿った形で作業を進めて行きます。今回の内容は２ページ分ですね。 事前情報 AMI は S3 に転送して保存する EC2 から S3 への転送料は課金対象外 イメージ化されるディレクトリは「/dev/sda1」のみ インスタンス 前々回の方法で、インスタンス起動まで進めます。 ssh 接続 今回は『AWS Management Console』を利用した手軽な接続方法を解説します。 AWS Management Console/EC2 から、左メニューの [Instances] をク
Kazuho@Cybozu Labs: blockdiff を使ったお手軽ホットバックアップ環境の構築 (Linux, MySQL, etc.)
一昨日に開催された hbstudy #7 にバックアップの話を聞きに行ってきました。Amanda を中心にした話で、とても勉強になりました。が、設定がめんどくさそうだなぁ、とも。自分の需要にはあわない感じでした。 勉強会が終わったあとで、自作のバックアップスクリプト blockdiff に関する話を何人かの方とさせていただいたのですが、思いのほか反応が良かったので、あらためて紹介したいと思います。 blockdiff は、一言でいうと、パーティションやデータベースのデータファイルの差分バックアップツールです。rsnapshot に似ていますが、rsnapshot ではデータベースのホットバックアップ不可能です。逆に blockdiff はディレクトリ単位でのバックアップには対応していないかわり、ファイルシステムやデータベースを、一貫性を保ちつつ実質無停止で差分バックアップすることができます
Tritonn のホットバックアップ(とsync ３回伝説) - kazuhoのメモ置き場
Tritonn のホットバックアップ環境を構築しようと思って調査。結論から言うと 漢(オトコ)のコンピュータ道: MySQLバックアップ頂上決戦！！ LVMスナップショット vs InnoDB Hot Backup の「MyISAMをスナップショットでバックアップ」でよさそう。 確認したこととしては、 Tritonn の全文検索データは FLUSH TABLES しても fsync されない つまり sync (1) の呼び出しが必須 linux の場合 sync (1) は１回呼べば十分だと man に書いてある POSIX 的には何回呼んでも書き込みが完了してる保証はない ってあたり。実際に、FLUSH TABLES WITH READ LOCK して sync ３回呼んでから LVM snapshot とって、myisamchk と sennachk してみたけど、myisamchk
MySQLバックアップ頂上決戦！！ LVMスナップショット vs InnoDB Hot Backup
スナップショットを使えばとある瞬間のディスクやファイルシステムのデータをいつでも後から参照することができる。しかもスナップショットの作成は一瞬だ。スナップショット機能を活用すれば最強のオンラインバックアップソリューションが出来るだろう。 しかし、スナップショットでバックアップを取るなんて危険な操作じゃないのか？！と不安に思われる方もいらっしゃるかも知れない。MySQL Serverが稼働中にいきなりデータだけをとってくるのだから、そのような疑問を持たれるのは頷ける。しかし仕組みさえ分かればスナップショットによるバックアップは怖くないということが分かるはずだ。そこで、まずはスナップショットによるバックアップの仕組みについて説明する。スナップショットを取る際の要件は次の通りである。 全てのデータを単一のボリュームに置くこと。つまり、一回のスナップショット操作でバックアップが取れることだ。 ディ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
http://www.machu.jp/posts/20081117/p01/