自動バックアップからのAzure SQL Databaseリストア設計 - Qiita
はじめに Azure SQL Databaseサービスを使う運用の場合、バックアップは原則自動バックアップを使う事になります。(自分でバックアップタイミングを指定したい場合はBACPACにファイルエクスポートする手段が一番簡易なのではないかと思います） ここではAzure SQL Databaseのバックアップ/リストア設計をするにあたり、実際本番環境DBサーバを復旧させるにあたっての具体的手順や状況別リストア方法の選択や注意点についてまとめたいと思います。 また、本文は2019/12月時点の情報で記載しています。 各リストア手法についての概要は、別の方がまとめて下さった↓がわかりやすかったです。 Qiita:Azure SQL Databaseリストア手法まとめ 注意事項/制限事項 設計にあたってAzure SQL Database特有の制限事項について先にまとめておきます。特にオンプレ
Azure SQL Databaseリストア手法まとめ - Qiita
Azure SQL Databaseのリストア手法がいくつかあったので纏めてみました。 バックアップ SQL Databaseではユーザが意識することなく、自動的にバックアップが取得されています。 取得タイミングはAzure側で決定されるため、ユーザが指定することはできません。 取得サイクル 完全バックアップ 毎週 差分バックアップ 数時間に1回 トランザクションログバックアップ 5～10分に1回 バックアップ保存期間はSQL Databaseのサービスレベルによって異なります。 保存期間 Basic 7日間 Standard 35日間 Premium 35日間 Point in Timeリストア 概要 同一サーバ内に新規データベースとして復元する手法 保存期間に合わせた任意の時間に復元することが可能 主な利用用途は、何か不具合発生時に過去に遡って検証したいケースが考えられます イメージ図
Azure SQL Database のユーザー追加方法 - poke_dev’s blog
基本的な考え方は、SQL Server と同じらしい。 SQL Database のユーザーは、インスタンス（サーバー）にログインする用の「ログインユーザー」と、インスタンスに含まれるデータベースを利用する用の「データベースユーザー」の 2 種類存在する。 インスタンスへのログインはログインユーザーを使用し（接続文字列とかで使用するログイン情報もこれ）、ログイン後のデータベース利用では当該ログインユーザーにマップされたデータベースユーザーが使用される。 特定のデータベースにのみアクセス可能なユーザーを追加するような場合、基本的にはログインユーザーとデータベースユーザー、それぞれについて追加が必要となる。 1 つのログインユーザーを複数のデータベースユーザーにマップする事も可能だが、各データベースユーザーにマップできるのは、1 ログインユーザーのみ。 データベースの権限設定は、ログインユーザ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
