米田です。
>プライマリが壊れない状態でのログのバックアップって
>使い道、あるのでしょうか？？？

>素人考えで言わせてもらえれば、プライマリとログが
>正常に保管してあるデータしか有効でないとなると
>ログを取らずに保管する方がシンプルで良い気がするのですが…。
　Backup のプランを仮想的に立て、それをもとに復旧できるデータ、できないデー
タを検討すると分かりやすいと思います。
特にトランザクションログバックアップは高頻度でバックアップを取りたい場合に
有用だと思っています。
--------------------------
(仮想例 あくまで仮想であり推奨ではありません)
　週に一度フルバックアップ
・ファイルサーバー データ領域全ファイル
・MS SQL Server 各データベース全体バックアップ
　容量が1本分を超えるため、DAT オートチェンジャ複数本に渡る。

　日に一度バックアップ
・ファイルサーバー データ領域アーカイブビットのたっているファイル
・MS SQL Server 各データベースのトランザクションログバックアップ

月曜昼、金曜昼にDATマガジン交換し、規定によりフルバックアップは一定期間保管
--------------------------
　この場合、トランザクションログバックアップにより容量を一応節約しつつ、日
次のバックアップを取ることができます。
日次であれば、各データベース全体バックアップも充分可能かもしれませんが、さ
らに頻度を上げてバックアップを取りたい場合、トランザクションログバックアッ
プは有用だと思います。

>対策としては、RAID か ミラーリングが有効なんですよね？
　これが対策になるのは、ハードディスクの(多分1台だけの)故障に対してだけで
す。
(もちろんそれも大きいですが)

　極感覚的には、排他でなく、同時に必要になると思っています。
「わざわざミラーリングして保護したいデータならバックアップを取らないなんて
不思議」という感覚です。
(逆にハードディスクが壊れたら諦めがつくデータなら両方とも不要ですよね)

　理由は
・ハードウエア的障害(HDD以外)
・ソフトウエア的障害(ブルースクリーン等)
・自分の開発したソフトの不具合
・管理者の操作ミス
・ユーザーの操作ミス
をRAIDやミラーリングは救ってくれません。
(都合の悪いデータを複数のHDDに広げるだけです)

　また障害対策でなくても開発者を目指すなら、バックアップ、リストア手順に習
熟しておくことは重要です。
開発用PCにデータを複写する場合に役に立ちます。また運用中のDBに異常を発見し
た場合、悠長に原因を探ることができるとは限りません。
・異常なDBをバックアップし現状確保
・前回の正常(と期待する)DBのリストアと運用再開
・開発PCへ異常DBをリストアし、調査と可能なら前回バックアップ後の作業結果の
救出

　私の場合、今年に入ってから役に立ったのは、
・ユーザーが誤って削除したデータの回復
・不具合調査用として送付
の2回でした。