SQL Server backup is a page-by-page physical copy of the database files. And, generally, the size of a backup is about the size of the database. However, there are several ways to cut the backup size substantially.
Reducing the backup size has the following benefits:
Starting from SqlBak app version 3.2.9, you can export a job to a JSON file and then import it using the SqlBak.Job.Cli.exe utility. This functionality is needed primarily for automated deployment of the SqlBak application and backup jobs creation. A simple tutorial on how to do this is described in the following blog post: How to deploy SqlBak app automatically.
The sqlbak.job.cli.exe utility is a programming interface for working with the SqlBak application. It is located in the root directory where the application is installed.
This tool can be used to register the application, manage connections to DBMS, and import jobs from JSON configurations.
When SqlBak is installed on a large number of servers, the deployment can be automated in 3 steps:
Storing backups only on a local disk is not a good practice, because you risk losing them if the disk becomes corrupted. It is recommended, therefore, that you send backups to multiple destinations to always be able to restore your databases. In this blog post, we will show how to create regular SQL Server backups and automatically send some of them to a local folder and some to the cloud (Azure Storage, for example) via SqlBak.
This article looks at different ways to back up SQL Server, from classic and conventional to exotic and situational.
But first, a few words of theory.
For the MySQL database to work quickly and without interruptions, it is necessary to perform maintenance jobs from time to time. This mostly just means running a few commands, but let’s address first things first.
One of the primary responsibilities of the DBA is to create regular backups. However, maintenance of the database is not limited to this.
The mechanisms that enable a relational database to run fast are based on a complex storage system that degrades over time. It leads to a general database slowdown.
The first thing a DBA should do after deploying a database is to ensure that backups are created regularly.
But storing a backup file on the same server where the MySQL server is located would be a big mistake. Therefore, you should create a backup and put it out of the server on which MySQL is located. The simplest solution would be to transfer it to another server via FTP.
The average lifespan of an SD card on a Raspberry Pi is two years. It is impossible to predict the date of failure of an SD card accurately. However, if you perform a regular backup of data on the card, its potential failure ceases to be an issue.