経緯

取引先の社内システムが「さくらのレンタルサーバ（php + MySQL）」で動いていて、
そろそろデータベースのバックアップも取り始めなきゃ…と思い、やりはじめる

実装

シェルかphpか

シェルで記述したんでいいかーと思っていたけど、今後バッチ処理として何かしたいことができたりしたときとか、さくらのレンタルサーバのCRON設定個数が5個までしかできないということを考えて、phpでバックアップ処理を実装することに。

ロジック

ものすごく単純。
稼働している3つのスキーマをmysqldumpでバックアップするだけ。
backupディレクトリに7日分保持。
過去のファイルは削除and削除。

どこに詰まったのか

さくらのレンタルサーバでCRONを設定するときには色々とクセが有ることが多く、ネットの各ページには

ユーザーディレクトリ（/home/username）に移動させて（cd）からでないとうまく動かない
実行ファイルはフルパスで書いておかないと動かない
とか書いてあったりして、少し混乱することがありますが、
基本は

/usr/local/bin/php /home/username/backup.php 1 >/dev/null

で大丈夫

コントロールパネルから設定してCRON動作を確認。
動いているっぽいからバックアップファイルを確認....と思ったところで問題発生。
バックアップファイルのファイルサイズが0バイト....

ディレクトリの権限を疑うものの、ファイルができてるから書き込み権限はあるはず。
ということでここから色々検証。

検証

１．プログラムが問題ないかを検証

phpで書いているプログラムなので、www以下に持っていって直接叩いてもいいし、
さくらのレンタルサーバはsshの接続もできるので、sshで接続してCRONに記述した内容をコピペで叩いてもいい。

ちなみに今回は後者を選択。
これでバックアップファイルがちゃんと書き込みされていることを確認。

２．-qオプションをつける

CRONも起動されているし、ファイル書き込み権限もあって、プログラム自体も正しく動いているのなら、これはさくらのレンタルサーバ固有の動き方のお話だろうと思ってとにかくググってググって...
というところで下記ページを確認
http://www.omnioo.com/record/else/mysqldump-q-cron/

exec("mysqldump -Q -u username -pPassword --default-character-set=binary -h XXXX.db.sakura.ne.jp username_db > $backup");

みたいな感じで実行してみる。
が、まだ0バイトファイル。。。。

３．mysqldumpをフルパスで書く

http://tanaka8.com/2014/12/mysqldump-php-cron/
上記のページに「コマンドまでのパスを記述しないと、cronでの実行に失敗します。」と書いてある。。。
でもsshから叩いたときは動いたけども？？？
と思いながら

exec("/user/local/bin/mysqldump -u username -pPassword --default-character-set=binary -h XXXX.db.sakura.ne.jp username_db > $backup");

と書き直して実行。

~~おお、動いたぞ…でもなんで…？？~~
コメントにて頂いたとおり、CRONでの実行時は環境変数がセットされていないです。
完全に失念。。。（インフラとかサーバーとか弱すぎて困る）

結論

まあ動きはしたものの、ちょっとしたことでつまづくなーというイメージ。
普通に使う以外はあまりさくらのレンタルサーバを使わないほうがいいのはわかってるけど、法人かつシステム担当が薄い法人にとってみると、さくらのレンタルサーバ（ビジネス）とかって便利だからねえ、難しいところ。
自分のスキル不足つらい。。。