📄
N2WS Backup & Recovery User Guide 4.3.0
  • 1 Introduction to N2WS
  • 2 Installing and Upgrading N2WS
  • 3 Start Using N2WS
  • 4 Defining Backup Policies with N2WS
  • 5 Consistent Backup with N2WS
  • 6 Windows Instances Backup with N2WS
  • 7 Linux/Unix Instances Backup with N2WS
  • 8 Using Elastic File System (EFS) with N2WS
  • 9 Additional N2WS Backup Topics
  • 10 Performing Recovery with N2WS
  • 11 Disaster Recovery with N2WS
  • 12 Cross-Account DR, Backup, and Recovery with N2WS
  • 13 File-Level Recovery with N2WS
  • 14 Tag-based Backup Management with N2WS
  • 15 N2WS Resource Control
  • 16 Security Concerns and Best Practices with N2WS
  • 17 Alerts, Notifications, and Reporting with N2WS
  • 18 N2WS User Management
  • 19 N2WS IdP Integration
  • 20 Configuring N2WS with CloudFormation
  • 21 Managing Snapshots with Lifecycle Policies with N2WS
  • 22 Configuring Workers with N2WS
  • 23 Capturing and Cloning in Network Environments with N2WS
  • 24 Orchestrating Recovery Scenarios with N2WS
  • 25 Monitoring Costs and Savings with N2WS
  • 26 Using N2WS with Azure
  • Appendix A Recommended Configuration for Copy to S3 with N2WS
  • Appendix B Agents Configuration Format with N2WS
  • Appendix C Time Zones with N2WS
  • Appendix D Datadog Integration with N2WS
  • Appendix E Splunk Integration Support with N2WS
  • Appendix F - Resetting Root Password or MFA in N2WS
  • Appendix G - Securing Default Certificates on N2WS Server
Powered by GitBook
On this page
  • 5.1 Crash-Consistent Backup
  • 5.2 Application-Consistent Backup
  • 5.3 N2WS and a Point in Time
  • 5.4 Summary or What Type of Backup to Choose
  • 5.4.1 Crash-Consistent
  • 5.4.2 Application-Consistent

5 Consistent Backup with N2WS

This section explains a few key concepts to help you use N2WS correctly.

5.1 Crash-Consistent Backup

By default, snapshots taken using N2WS are Crash-consistent. When you back up an EC2 instance at a certain time, and later want to restore this instance from backup, it will start the same as a physical machine booting after a power outage. The file system and any other applications using EBS volumes were not prepared or even aware that a backup was taking place, so they may have been in the middle of an operation or transaction.

Being in the middle of a transaction implies that this backup will not be consistent, but this is not the case. Most modern applications that deal with important business data are built for robustness. A modern database, be it MySQL, PostgreSQL, Oracle, or SQL Server, has transaction logs. Transaction logs are kept separately from the data itself, and you can always play the logs to get to a specific consistent point in time. A database can start after a crash and use transaction logs to get to the most recent consistent state. NTFS in Windows and EXT3 in Linux have implemented journaling, which is not unlike transaction logs in databases.

5.2 Application-Consistent Backup

During application-consistent backups, any application may be informed about the backup progress. The application can then prepare, freeze, and thaw in minimal-required time to perform operations to make sure the actual data on disk is consistent before the backup starts, making minimal changes during backup time (backup mode) and returning to full-scale operation as soon as possible.

There is also one more function that application-consistent backups perform especially for databases. Databases keep transaction logs which occasionally need to be deleted to recover storage space. This operation is called log truncation. When can transaction logs be deleted without impairing the robustness of the database? Probably after you make sure you have a successful backup of the database. In many cases, it is up to the backup software to notify the database it can truncate its transaction logs.

5.3 N2WS and a Point in Time

When taking snapshots, the point in time is the exact time that the snapshot started. The content of the snapshot reflects the exact state of the disk at that point in time, regardless of how long it took to complete the snapshot.

5.4 Summary or What Type of Backup to Choose

The type of backup to choose depends on your needs and limitations. Every approach has its pros and cons:

5.4.1 Crash-Consistent

Pros:

  • Does not require writing any scripts.

  • Does not require installing agents in Windows Servers.

  • Does not affect the operation and performance of your instances and applications.

  • Fastest.

Cons:

  • Does not guarantee a consistent state of your applications.

  • Does not guarantee the exact point in time across multiple volumes/disks.

  • No way to automatically truncate database transaction logs after backup.

5.4.2 Application-Consistent

Pros:

  • Prepares the application for backup and therefore achieves a consistent state.

  • Can ensure one exact point in time across multiple volumes/disks.

  • Can truncate database transaction logs automatically.

Cons:

  • May require writing and maintaining backup scripts.

  • Requires installing an N2WS Thin Backup Agent or the AWS SSM Agent for Windows Servers.

  • May slightly affect the performance of your application, especially for the freezing/flushing phase.

Previous4 Defining Backup Policies with N2WSNext6 Windows Instances Backup with N2WS

Last updated 11 months ago