Planification des sauvegardes

Last modified by Equipe Opération on 23 - 04 - 2019

Implementing a proper backup schedule

To optimize your backup strategy with Nuabee Backup, you need to think about your scheduling plan taking accounting for the backup types, data weight and your IT use / availability time slots to avoid conflicts and bottlenecks.

Disclaimer : The estimated durations are just an example and will vary depending on a number of factors like your uplink speed, disk size and type and infrastructure used.


The following features allows you to adapt your software and resource use to best fit your needs.

Managing scheduling and frequency

Nuabee Backup enables you to manage when and at which frequency the software should backup your data and allowing to define exclusions to limit the backup to necessary data

A few examples:
  • Backup everyday on the week except on wednesday where bandwidth is limited for the office.
  • Every third wednesday of every two months towards warm storage for legal reasons.

It is recommended to define the backup time slots outside of usual infrastructure use to avoid bottlenecking the network and limiting the impact on users and your internet connection.

Block backup, Managing Incremental and Full

Block backup essentials

This mode enables the incremental / complete backup options.

During an incremental backup, the block mode only records the modified parts / blocks since the last backup, saving time and bandwidth.

But during a Full backup, the entirety of the file is backed up.

More informations about block level blackup

Full backup planing

During the backup planing definition, it's usual to use a regular incremental backup to limit the amount of uploaded data.

To avoid issues, enhance backup reliability and restore performance, it's necessary to plan a longer full backup every few backups.

For example, a full backup once a week when daily incremantals are setup.

Retention and purge options

Numerous versionning strategies are available to you, either

  • through a set number of versions to keep (useful for office files for example)
  • through a set number of days / weeks /months after last backup or modification date
  • combining the two above

Limiting backup plan duration

To avoid bottlenecks and impacts over the production, backup plans can include an execution limit it to a certain amount of time.

For example, a SQL Server backup that takes too much time can be stopped to be restarted after the usage spike is over, avoiding transaction logs overflow and slowdowns.

  • If the time limit is reach, the plan will be reported as failed.
  • You should review your backup planning and strategy to avoid those cases, you can free up space on the server, change approach (splitting into multiple plans) or assign more resources to the server.

Optimizing bandwidth use

Data compression

Nuabee Backup allows you to compress your backed up data to minimize the amount of data uploaded, the option is a checkbox to tick when specifying your encryption key.

Bandwidth limit scheduler

You can avoid strain during the day by setting a limit to your client's bandwidth usage based on a schedule.

For example, you can specify that during opening hours, only 200KB/s of bandwidth is available, 1MB/s between 1pm and 2pm and back down for the afternoon.

You can limit local and cloud bandwidth speed separately.

Anticipate conflicts

Third party VSS components

To avoid conflicts with another backup software and reduce the impact of two backup software cohabitation, Nuabee Backup can either use it's own VSS writers or the system's own VSS components.

Avoid plan overlap

Plans overlap may induce general slowdowns, bandwidth saturation and simple VSS conflicts. To avoid those, you can use backup plan chaining.

Caution : only chain differential backup plans, create separate full backup plans when using differential chaining.

Backup types

Take note that application specific backup types such as SQL Server and Exchange, running in parallel to other backup types may induce a VSS resource access conflict.

Two backup plans accessing the same resources cannot run at the same time.

Windows Backup

Image Backup

Windows image backup are recommanded for system disks and mandatory for DR, they ensure consistent data and are block level backup capable.

A classical planning is comprised of a daily differential image backup coupled with a weekly full backup (usually planned during the week-end).

File Backups

File backups enable finer grained control of backup operations for filers and individual folders, but induces a longer backup and restore time.

This mode is recommanded for editable office files to enable proper versioning management, using backup planning the same way as Image backups and modification / backup date triggers.

You should think about your planning carefully, filer backups are generally long, managing a huge number fo files / entries, so plan your backup strategy around a clean separation of the amount of files that are modified with a set frequency and those that don't require to be scanned as frequently.

Moving those parts to another Drive letter as well as moving the Nuabee Backup internal database to an SSD based volume can help your backup time significantly.

SQL Server Backup

SQL Server backup are specifically conceived to backup the database with it's transaction logs (without trunking capability) to enable you app level recovery, tightly integrated with Microsoft SQL Server backup mechanisms.

Those backups are usually long and complex, assigning more resources to the server, moving Nuabee Backup database to SSD based volumes and properly selecting the affected dataset should be your priority.


File based backup

File based options work the same way on Linux as they do on Windows and MacOS.

Sauvegarde Image Linux (ReaR)

Linux image based backups are usually setup for DR, and the default planning for those is a daily differential and weekly full backup during the week-end.

Multiple backup plans on the same server

For some servers, you will need multiple backup plans to properly cover all of it's data and / or enable DR. So here is an example if you are faced with this case, we are here displaying a possibility for a SQL Server running Windows Server machine.

  • Local Image (estimated to last 5 hours)
    • Differential from monday to thursday 5:30pm
    • Full on Friday at 5:30 pm
  • Cloud Image
    • Differential from monday to thursday 11pm
    • Full on Friday at 11pm
  • SQL Server app data backup :
    • Every 4 hours for transaction logs
    • Weekly / Bi-weekly Full (depending on data volume) on saturday 10pm