• pdanes (10/17/2012)

    I agree as well - recovery is the ultimate goal, but once again, I can't even attempt a recovery if I haven't made a backup, and I can't make a regularly scheduled backup if I don't have some sort of plan. Testing restores is all well and good, but that comes AFTER having made a backup, to ensure that the backup was done correctly, and that it's useable.

    Simplicity was exactly my thought - with a small database, does mixing full, differential and transaction backups make sense, or is it unnecessarily complicated? Obviously, a full backup once per minute would be the simplest from a recovery standpoint, but that's hardly practical.

    You think, then, that such a cascaded full/differential/transaction approach makes sense, even given the situation I've described? If so, may I ask for your reasoning on the matter? It appears overly complex to me, but maybe I'm missing something, which is, after all, why I posted my original question.

    Well, it also depends on how small we're talking and how comfortable you are with backups in general.

    Personally, I'm currently running a small test server, and I do just as I've described, because I like knowing I can back up from any point.

    This is honestly one where it really depends on you and your comfort zone. If you feel that a weekly full and a daily differential are sufficient, then go for it. I'd also try "breaking" it at some point too; if your backup is corrupted, if your backup just doesn't restore, whatever, so you can learn how to fix it too.

    I guess my feeling is you said before that you wanted to practice. Doing the full monty here will help you with that, and for larger databases I know best practices recommend fulls/diffs/trans. So you might as well go whole hog to start with.

    But this is just my opinion; feel free to take it with a grain a salt! 😀

    _____________________________________________________________________
    -Jamie Scharbrough
    MCTS: SQL 2008R2