What will change?
Currently, SqlBak has access to all files and folders on Google Drive. Now, SqlBak will request access only to the files and folders on Google Drive created by SqlBak.
Currently, SqlBak has access to all files and folders on Google Drive. Now, SqlBak will request access only to the files and folders on Google Drive created by SqlBak.
If a database that should be backed up via SqlBak is not particularly large, then there is no need to set compression options in a specific way. It is recommended to use the default values.
The features below are designed to fine-tune compression for highly loaded systems and large databases.
If you specify a password in the “Encrypt compressed files” section, then the backup files will be encrypted.
This guide contains recommendations for setting up a SqlBak backup job. This information has been developed and collected over years of interaction with SqlBak users. There will be no theory and formulas, only practical advice.
Note that these practices are not the only solutions. They are suitable in most cases, but can be fundamentally wrong under various circumstances.
Let’s consider the steps that are used to set up a backup job.
Differential and transaction log backups are available only for local SQL Server connections. If you backup SQL Server using SqlBak, then you can add differential or transaction log backups to your backup plan in the “Advanced backup schedule” settings.
In one database management system, there can be multiple databases. When creating a backup job, you can choose which databases specifically need to be backed up. The backup of each database will be made independently from the other databases and placed in a separate archive.
SqlBak supports sending to 16 different storage types. In one job, you can specify multiple backup storage locations, and for each storage location, you can specify the duration of backup storage on it.
For large data volumes, backup job execution can take a lot of time. However, there are several tricks that can help optimize the time.
Point-in-time recovery is the concept of restoring data to a particular time in the past.
Suppose you deleted an important database table at 2 p.m. on a Wednesday. You realize this fifteen minutes later and you need to restore the data. Replication will do you no good, because the table in the replica has also been deleted. Only backups can save the day.
However, if you back up your data at 1 a.m. every day, the closest recovery point to when the table was deleted will be at 1 a.m. that Wednesday. When you restore data, you will lose 13 hours of data. But if you use the point-in-time recovery strategy, you can recover data as of 1:55 pm, losing only 5 minutes!
Incremental backup is a backup that only contain data that has changed since the previous backup, not including all the data in the database.
Incremental backups allow performing backups much more frequently, as they are much smaller in size. However, to restore from an incremental backup, not only the incremental backup file is required, but also the entire preceding chain of backups.