Dimitry SibiryakovCammomileВ течение дня можно протерять то/, что "машенька-оператор" сегодня занесла ручками, это
значит, что завтра ей предется сделать двойную работу, если прямо вот все за сегодня потеряно.

То есть делать бэкап раз или два в сутки вполне достаточно. А стратегию погугли, там
хитрое повторное использование носителей (очистки бэкапов), благодаря которому достигается
компромисс между занимаемым бэкапами местом и глубиной возможного восстановления.

Глубина возможного восстановления важна, если возможна ситуация "Ой, мы 3 дня назад убили в базе важную информацию, поэтому вчерашний и позавчерашний бекап не подходят, а нужен недельной давности". Если такого быть не может (а судя по описанию, так и есть) - да, снимать полный бекап раз в день ночью, автоматом поднимать на тестовый сервер, прогонять проверочные скрипты (скажем, checkdb + сверка кол-ва записей в основных таблицах), в случае успеха раскладывать на 2 различных дисковых массива и закачивать в пару облаков (опционально при этом шифруя), благо объемы детские и даже бесплатных облаков хватит с лихвой.

CammomileКот Матроскин,

авторГлубина возможного восстановления важна, если возможна ситуация "Ой, мы 3 дня назад убили в базе важную информацию, поэтому вчерашний и позавчерашний бекап не подходят, а нужен недельной давности".

А разве FULL RECOVERY не подразумевает возможности откатить БД до определенной точки?
FULL RECOVERY - это полный бекап на некий момент + бекапы всех логов изменений с тех пор. Восстановиться, соответственно, можно на точку между этим "неким моментом" и последним бекапом логов.
Теоретически - да, можно сделать полный бекап на 1 января, весь год бекапить только логи и иметь возможность откатиться на любой день в году, но практически так никто не делает без острой необходимости, потому что
1. время поднятия бекапа начинает возрастать пропорционально количеству накопившихся логов.
2. регулярная проверка этих бекапов логов превращается в нетривиальную процедуру
соответственно, надежность конструкции падает.