Update app-consistent recovery points performance guidance for DB

[aktsmm]

Clarified performance impact and backup frequency recommendations for app-consistent recovery points.

Description

This PR updates the backup guidance for database workloads (including Azure Site Recovery).
The previous text stated only that "one hour should be enough," which could be misinterpreted as implying that hourly full backups alone are always sufficient.
In reality, if the Recovery Point Objective (RPO) is one hour, then full backups alone may be acceptable. However, in many systems shorter RPOs are required, which makes frequent transaction log backups (e.g., every 10–15 minutes) combined with less frequent full backups the standard approach.

Rationale for Change

• Clarify the dependency on recovery objectives: "One hour is enough" is only true when the RPO requirement is one hour. Backup frequency must align with requirements, not arbitrary defaults.
• Emphasize the role of transaction log backups: For shorter RPOs, transaction log backups at short intervals are essential. They balance recovery objectives with system performance.
• Tie to business continuity goals (RPO/RTO/RLO): Backup strategies should be explicitly aligned with recovery objectives, making the guidance more actionable for architects and operators.

Impact

This change clarifies that "one hour should be enough" means sufficient only if the RPO requirement is one hour.
It prevents misinterpretation that hourly full backups alone are always adequate, and instead highlights that log backups are generally required for practical, best-practice database recovery planning.

[prmerger-automator]

@aktsmm : Thanks for your contribution! The author(s) and reviewer(s) have been notified to review your proposed change.

[learn-build-service-prod]

Learn Build status updates of commit ec40764:

✅ Validation status: passed

File	Status	Preview URL	Details
articles/site-recovery/azure-to-azure-common-questions.md	✅Succeeded

For more details, please refer to the build report.

[v-dirichards]

@jyothisuri

Can you review the proposed changes?

Important: When the changes are ready for publication, adding a #sign-off comment is the best way to signal that the PR is ready for the review team to merge.

#label:"aq-pr-triaged"
@MicrosoftDocs/public-repo-pr-review-team