SSMSで見るのもいいが、sqlで取得できるといろいろ捗るので。
SELECT database_name, principal_server_name, mirror_server_name, safety_level, partner_sync_state, partner_sync_state_desc FROM sys.database_mirroring_witnesses
ミラーリング監視サーバでsqlcmd経由で定期的に発行させ確認するとか。
QNAPに「さくらのVPS」のシステムバックアップを自動でおこなう③
QNAPで設定
ポイントをおさえておけば設定自体は難しくない（が、制約もあることに注意）
- 事前にリモートバックアップの情報を「ストレージ領域」として作成する
- リモートからローカルNASへのバックアップは「アクティブ同期」（名前がわかりにくい）を指定する
- インターネット経由でのバックアップの場合は、暗号化する事が望ましいが 暗号化が可能なSSH経由のRSYNCの場合、rootでログインしないとファイルのアクセス権限の理由で、バックアップに失敗する場合がある（rsync-path='sudo rsync')してくれないっぽい？
AppCenterからHBS3 Hybrid Backup Syncをインストールする
バックアップ系はここに集約しているようなので、これをインストールする
左アイコンの一番下をクリックし、ストレージ領域の作成ボタンを押下して領域を作成
リモートRSYNCを選択。
Rsyncの設定に基づいた設定の実施
RSYNCの場合
- 名前：わかりやすいのをつける
- IPアドレス/ホスト名：さくらのVPSのホスト名
- ポート：特に変更してなければデフォルトの873を指定
- サーバの種類：Rsync互換サーバ
- アカウントアクセス：rsyncサーバアカウント
- ユーザ名：rsyncd設定の時に設定したID
- パスワード：rsyncd設定の時に指定したパスワード
- 暗号化ポートを使用する：選ばない（チェックするとSSH経由になる）
RSYNCをSSH経由で実施する場合（暗号化ポートを利用する）
- 名前：わかりやすいのをつける
- IPアドレス/ホスト名：さくらのVPSのホスト名
- ポート：SSHのポート 通常は22。攻撃が多いポートのため、変更を推奨。
- サーバの種類：Rsync互換サーバ
- アカウントアクセス：rsyncサーバアカウント
- ユーザ名：SSHアカウント
- パスワード：SSHパスワード
- 暗号化ポートを使用する：選ぶ
同期ジョブの作成
同期を選択。
作成→アクティブ同期
リモートRSYNCサーバを指定
さきほど作ったストレージ領域を「選択」
同期先をそれぞれ選択
- リモート /timeshift /backup等 バックアップファイルを格納したフォルダ
- ローカル /任意のバックアップ場所
スケジュールの設定
ソースフォルダから消えたものは、削除するように設定。
QNAPに「さくらのVPS」のシステムバックアップを自動でおこなう②
postgresqlのDBバックアップ
/var/lib/postgresql/bkup_daily.sh [任意の場所]
postgresqlユーザで実行するので、postgresのホームディレクトリにおいてある。
# backup /usr/bin/pg_dumpall -f /backup/today_bkup.sql /usr/bin/zip --encrypt --password xxxxxx /backup/postgres_`date "+%Y%m%d_%H%M"`.zip /backup/today_bkup.sql /usr/bin/rm /backup/today_bkup.sql # old-backup-delete /usr/bin/rm `ls -t /backup/* | tail -n+8`
- pg_dumpallで出力したあと、/backupへ暗号化ZIPで日付ファイル名で出力。
- 7世代より古いファイルは削除する。 -n+8の数字をかえることで世代数は変更可能。(世代数が少ないうちは削除エラーがでるが、動作上問題がないのでよしとする)
出力先は/backupにしてあるが任意の場所でOK。postgresユーザで書き込みできる権限にしておく。
chmod +x /var/lib/postgresql/bkup_daily.sh
crondから実行するので実行権限をつけておく。
crondの設定
$ crontab -e 0 4 * * * /usr/bin/sh /var/lib/postgresql/bkup_daily.sh >/dev/null 2>&1
上記の例は毎日朝の4時にバックアップをとる設定にしてある。
Timeshiftの設定
ubuntu20.04であれば、apt install timeshiftでインストール可能。 最新版をインストールしたい場合は、以下の手順。
$ sudo add-apt-repository -y ppa:teejee2008/timeshift $ sudo apt-get update $ sudo apt-get install timeshift
外部ディスクを利用できればいいが、VPSなので同じディスクを指定。
スケジュールは任意。システムバックアップなので、基本は大きな更新作業前に、手動でとっておくのがよい。
取り忘れのために、週次と月次で1世代だけとるようにした。
ホームディレクトリはデフォルトで隠しファイル以外は対象外となっている。自分の使い方ではこちらもバックアップ必要なので加えてある。
QNAPに「さくらのVPS」のシステムバックアップを自動でおこなう①
本日の目的
さくらのVPS上に構築しているubuntu20.04のシステムバックアップ＆データバックアップを自宅のNASであるQNAPの機能を使って実装する。
前提条件
- システムバックアップはtimeshiftを利用する
- システムバックアップは任意のタイミング（手動で大きなアプリを導入等）
- DBは日次バックアップする
- QNAPのGUIから操作できるものとする
手順
- さくらVPS上のubuntuにqnap経由でrsyncできるように設定する
- crondによりpostgresのDBをn世代取得する
- TimeShiftによるubuntuのシステムバックアップ
- QNAP上でのバックアップ設定
さくらVPS上のubuntuにqnap経由でrsyncできるように設定
大きく分けて2パターンの手順がある。 -手順1 rsyncdを有効 = 確実だが、経路が暗号化されない -手順2 ssh経由での接続 = 経路はsshにより暗号化されるが接続条件の一部が不明
どちらかで実施する。 手順1は、少し作業が多いが確実に動く（と思う） 手順2は、rsync用のユーザを作成しsudo/no passwordでrsyncできるような設定で動作を確認している。 一部不正確な部分もあることを了承してほしい。
手順1（RSYNCで直接連携させる）
rsyncdの設定ファイル＋パスワードファイル、設定を有効化してrsyncを再起動させる必要がある。
/etc/rsyncd.conf [新規作成]
$ sudo nano /etc/rsyncd.conf
#
# Global options
#
uid = root
gid = root
hosts allow = xxxx.myqnapcloud.com
hosts deny = *
list = true
dont compress = *.gz *.tgz *.zip *.pdf *.sit *.sitx *.lzh *.bz2 *.jpg *.gif *.png
#
# Module options
#
[timeshift]
path = /timeshift/
read only = false
auth users = user1
secrets file = /etc/rsyncd.secrets
QNAPのDDNSサービスを利用して、QNAP（自宅インターネット回線のIP）からのみ接続可能に設定。 他にもバックアップをとりたいフォルダがある場合は、それぞれ増やせばよい。
/etc/rsyncd.secrets [新規作成]
$ sudo nano /etc/rsyncd.secrets
user1:[password] user2:[password]
IDと認証パスワードのファイルとなる。
sudo chmod 0600 /etc/rsyncd.secrets
パスワードがそのまんま書いてあるのもあるので、root以外はアクセス不可にパーミッション変更する。
rsyncd（サーバ）の有効化準備
/etc/default/rsync [変更]
$ sudo nano /etc/rsyncd.secrets
RSYNC_ENABLE=true
rsyncの再起動（設定の有効化）
$ sudo systemctl restart rsync
手順2(SSH経由でRSYNCさせる)
rsync用のアカウントを作成。
$ sudo adduser rsync_op
ntoh@moooi:~$ sudo adduser rsync_op
ユーザー `rsync_op' を追加しています...
新しいグループ `rsync_op' (1005) を追加しています...
新しいユーザー `rsync_op' (1005) をグループ `rsync_op' に追加しています...
ホームディレクトリ `/home/rsync_op' を作成しています...
`/etc/skel' からファイルをコピーしています...
新しいパスワード:
新しいパスワードを再入力してください:
passwd: パスワードは正しく更新されました
rsync_op のユーザ情報を変更中
新しい値を入力してください。標準設定値を使うならリターンを押してください
フルネーム []:
部屋番号 []:
職場電話番号 []:
自宅電話番号 []:
その他 []:
以上で正しいですか? [Y/n]
必要な情報を追加。password等を設定
$ visudo [追記] rsync_op ALL=(ALL) NOPASSWD:/usr/bin/rsync
おまじない
該当ユーザでdesktop(VNCコンソールでも可)で一度ログインする。 これをしないと、なぜかqnap上の登録の途中で実施するテストに権限不足エラーが発生した。
TinyTinyRSS(TT-RSS)をアップデートしたらエラーになった#2
今日も今日とてgit pullして、二日連続同じトラブルにあったなり。
とくにerror.log等にも手がかりがないので、エラーメッセージから辿ってみた。
: classes/handler/public.php:848 msgid "Your access level is insufficient to run this script." msgstr "あなたの権限では、このスクリプトを実行できません。"
該当の部分はここっぽい。
if (!Config::get(Config::SINGLE_USER_MODE) && $_SESSION["access_level"] < 10) { $_SESSION["login_error_msg"] = __("Your access level is insufficient to run this script."); $this->_render_login_form(); exit; }
access_levelをあげれば通るっぽいので（無茶な理論）、直接DB側で変更したらなんとか入れるようになった。
ちなみにgit pullでアップデートした結果、データベースのバージョンアップ作業が求められていたっぽいので、たんに管理者権限ではいればよかったっぽいです。（管理者はaccess_level=10）
TinyTinyRSS(TT-RSS)をアップデートしたらエラーになった
何も考えずに、git pullしたら起動しなくなったという話。
Exception while creating PDO object:SQLSTATE[08006] [7] FATAL: role "www-data" does not exist
どうもconfig.phpの方式が変わったらしく、defineからputenvで指定する新しい形式に変更しないとダメのもよう。
For any config.php settings you have changed from the defaults (normally this is the DB_ group of settings and SELF_URL_PATH, replace as follows, using the rules above: define('DB_PORT', 'xxx') → putenv('TTRSS_DB_PORT=xxx'). You can safely omit any settings that were at default values. This thread has relevant discussion and many examples.
GlobalConfig - tt-rss - Tiny Tiny RSS
一部のプラグイン用の設定は、defineで指定しないと動かないとか。とりあえず、DB周りの設定と、SELF_URL_PATH関連をputenvで指定するように変更したら動いた。 時間があるときに、ちゃんと見直す。
<?php putenv('TTRSS_DB_TYPE=pgsql'); // pgsql or mysql putenv('TTRSS_DB_HOST=localhost'); putenv('TTRSS_SELF_URL_PATH=https://moooi.jp/xxx'); putenv('TTRSS_DB_USER=ttrss'); putenv('TTRSS_DB_NAME=ttrss'); putenv('TTRSS_DB_PASS=xxxx'); putenv('TTRSS_DB_PORT=5432'); // usually 5432 for PostgreSQL, 3306 for MySQL