Backup and restore information. The best backup software

from viruses and software errors, hardware failure or human error, there are many potential dangers infecting your files.

And it can happen even worse - for example, losing personal photos, music library, important business documents - something that can be really valuable. That is why it is necessary to create backup your computer automatically.

It is very difficult to do it yourself, but with the right software that it will be much easier than you think. Without any cash costs, because there are some free disk backup and cloning software.

If you want to, copy the contents of your documents somewhere , clone one drive to another, or back up your entire system I have found many programs that can help.

Action Backup

Action Backup - perhaps best files scheduled for home and work computers. The program is very convenient, as it combines ease of use, as well as wide functionality for performing backups. With Action Backup you get: support for full, differential, incremental backups, automated* backups to FTP servers, CD/DVD, remote network resources, support for zip64 format, support for " shadow copy", work in the mode windows services*, automated removal of previous (obsolete) archives*, sending a report to e-mail and much more ( detailed description functionality is available on the official website of the developer).

Action Backup is perfect for both beginners and advanced users, making it an excellent tool for backing up files on home computers, as well as workstations and servers.

* - available only in the paid version. There is a version comparison on the official website.

Aomei Backupper

If you like backup software, Aomei has a simple interface. Select the drive or partition to be backed up, the destination drive, and click Backupper will create an image.

The program has good enough tools if you need it. There are options to encrypt or compress backups. You can create incremental or differential backups to increase speed. You can restore individual files and folders, or the whole image and there are even disk and partition cloning tools.

What you can't do unfortunately Backup Scheduled- they must be started manually. But otherwise Aomei Backupper is a great tool, with a huge number of features, but also easy to use.

EASEUS Todo Backup Free

Like most free (for personal use) programs of commercial products, EASEUS Todo Backup Free has a few limitations - but the package still has more than enough features for most people.

The program can run both file and file based backup, such as manually or scheduled. Are you able to work with full or incremental backups.

The ability to limit the write speed reduces the impact of backup on system performance. This is possible in individual files or folders, or the entire image using the recovery disk program. And there are tools to clone and format drives too.

On the negative side, you get no encryption, no differential backup, and you only get a disk-based Linux (not Windows PE). But EASEUS Todo Backup Free still looks like a great program for us.

Redo Backup and Recovery

Redo Backup and Recovery — is a visualization backup tool with a difference. Instead of installing the program, you need to download a large (249MB) ISO file and burn it to a CD or a USB drive. Then just boot from it to launch a simple tool that can backup your hard drive and restore them later.

There's also a recovery tool, and even a web browser if you need help with a PC problem.

The program is not very user friendly. You can't schedule backups, they all have to be started manually and there are very few options.

But it's also easy to use and free for everyone, so if you want to run a backup sometimes, you can use it on any computer without installing software, then this product is for you.

Cobian Backup

Cobian Backup is an excellent software backup tool, with a lot of features. You get full, differential and incremental backups, for example; ZIP or 7zip compression; AES 256-bit encryption; include and exclude filters; scheduler, backup or FTP servers, and the list goes on. Every aspect of the program is extremely customizable (there are over 100 settings you can customize).

PC or backup, beginners will most likely find it very difficult. If you are more experienced you will love the number of tools Cobian Backup gives you control over every aspect of the backup process.

Macrium Reflect Free

One of the most popular free (for home use) disk imaging programs, Macrium Reflect Free the main set of functions through the interface is easy to use.

The program does not have incremental or differential backups. And you won't get encryption or password protection. It makes creating a backup very easy though (choose your source drive and set the compression ratio, done).

There is a scheduler; You can mount images in Windows Explorer or completely restore them both from Linux and disks Windows recovery PE. And in general Macrium Reflect Free An excellent choice for those who want a simple yet reliable image backup tool.

DriveImage XML

Free for personal use, DriveImage XM is an easy alternative to more advanced competitors. Backing up is as easy as choosing a source drive, a destination and (optionally) setting a compression level.

Recovery is just as simple, and the only significant extra is the ability to copy directly from one drive to another.

There are some complications elsewhere. Click the "Task Scheduler" button and you will receive instructions on how to manually configure Windows Task Scheduler to start the backup. But if you only need a basic visualization tool then give DriveImage XML handle.

FBackup

FBackup is good remedy file backup, free for personal and commercial use. The interface is simple and clear, and there are a number of features.

Plugins allow you to create backup copies of individual programs with one click; there is support for including and excluding filters; and you can run "Mirror" backups which just copy everything without compressing it (which makes file recovery very easy).

The compression isn't as good though (it's a weak Zip2), and the scheduler is also simpler than you'll find in other programs. But if your needs are simple then FBackup should suit you.

Backup Maker

First free for personal use BackupMaker seems like any other backup file tool program, with additional or full backups available, scheduling, compression, encryption, include and exclude filters, and so on.

But interesting Additional services include support for online backup on FTP servers, and when executing backup automatically, When USB device connected.

Program data is stored in Zip files, too, which makes them very easy to access. AND BackUp Maker comes in a small 6.5Mb installation package, much more manageable than some of the bulky competitors.

If you are a home user looking for file backup method, then backup Maker could be perfect.

clonezilla

Just like repeat backup and restore, clonezilla not installer: it is dos boot environment which can be run from a CD or USB flash drive.

And it's serious powerful program, too: you will be able to create a disk image; restore the image (to one disk, or to several at the same time); clone a drive (copy one drive to another), with a lot of control.

While Repeat Backup and Restore focuses on ease of use, however, clonezilla more about providing additional options like "unattended clonezilla by using PXE boot". It's not difficult, probably the best free program for disk cloning - but the program is aimed at advanced users and backup, for beginners it is better to find a more suitable option.

Paragon Backup & Recovery 2014 Free

Another free program for personal use, Paragon Backup & Recovery 2014 Free
is good tool, with some restrictions.

Strong support for the foundation: you can create an image backup(full or differential), compress and encrypt them, use exclusion filters to help determine what is included, do scheduled backups, and then restore individual files and folders or all of them.

Optional includes separate section, help keep your backups safe. And a nice set of basic section tools are included.

Problems? You won't get incremental backups; You can't clone drives or partitions, and the interface doesn't feel very good at times. Nevertheless Paragon Backup & Recovery 20134 Free quality tool, and worth your attention.

Duplicati

If you need online backups, then Duplicati is one of the most versatile tools, with support for saving files skydrive, Google Docs, FTP servers, Amazon S3, Rackspace Cloudfiles and WebDAV.

The program can also save to local and network drives, although it includes many useful options (AES-256 encryption, password protection, scheduler, full and incremental backups, regular expression support to enable/disable filters, even upload and download rate limits to reduce the impact on your system).

So whether you save files online or locally, then this program is for you.

Preparing a new server for work should begin with setting up backup. Everyone, it would seem, knows about it - but sometimes even experienced system administrators make unforgivable mistakes. And the point here is not only that the task of setting up a new server needs to be solved very quickly, but also that it is far from always clear which backup method should be used.

Of course, it is impossible to create an ideal way that would suit everyone: everywhere there are pluses and minuses. But at the same time, it seems quite realistic to choose a method that is most suitable for the specifics of a particular project.

When choosing a backup method, you should first of all pay attention to the following criteria:

1. Speed ​​(time) of backup in storage;
2. The speed (time) of restoring from a backup;
3. How many copies can be kept with a limited storage size (backup storage server);
4. The volume of risks due to the inconsistency of backups, the lack of debugging of the method for performing backups, the complete or partial loss of backups;
5. Overhead: the level of load created on the server when performing a copy, a decrease in the response time of the service, etc.
6. The cost of renting all used services.

In this article, we will talk about the main ways to back up servers running Linux systems and about the most typical problems, which newcomers to this very important area of ​​system administration may encounter.

Scheme of organization of storage and recovery from backups

When choosing a scheme for organizing a redundancy method, you should pay attention to the following basic points:

1. Backups cannot be stored in the same location as backed up data. If you store a backup on the same disk array as your data, then you will lose it if the main disk array is damaged.
2. Mirroring (RAID1) cannot be compared to backup. The raid only protects you from a hardware problem with one of the disks (and sooner or later there will be such a problem, because the disk subsystem is almost always the bottleneck on the server). In addition, when using hardware raids, there is a risk of controller failure; it is necessary to keep its spare model.
3. If you store backups within the same rack in the DC or just within the same DC, then in this situation there are also certain risks (you can read about this, for example, .
4. If you store backups in different DCs, then the network costs and the speed of restoring from a remote copy increase dramatically.

Often the reason for data recovery is damage file system or disks. Those. backups need to be stored somewhere on a separate storage server. In this case, the "width" of the data transmission channel may become a problem. If you have a dedicated server, then it is highly desirable to perform backups on a separate network interface, and not on the same one that exchanges data with clients. Otherwise, your client's requests may not "fit" in a limited communication channel. Or, due to client traffic, backups will not be made on time.

Next, you need to think about the scheme and time of data recovery in terms of storing backups. You may be fine with a 6-hour nightly backup on a limited-speed storage, but a 6-hour restore is unlikely to suit you. This means that access to backups should be convenient and the data should be copied quickly enough. So, for example, restoring 1TB of data with a bandwidth of 1Gb / s will take almost 3 hours, and this is if you do not “rest” on the performance of the disk subsystem in the storage and server. And do not forget to add to this the time to detect a problem, the time to decide on a rollback, the time to check the integrity of the restored data, and the amount of subsequent customer/colleague dissatisfaction.

Incremental backup

At incremental A backup only copies files that have changed since the previous backup. Subsequent incremental backups only add files that have changed since the previous one. On average, incremental backups take less time because fewer files are backed up. However, the data restore process takes longer because the data from the last full backup must be restored, plus the data from all subsequent incremental backups. In this case, unlike differential copying, changed or new files do not replace the old ones, but are added to the media independently.

Incremental copying is most often done using the rsync utility. With it, you can save storage space if the number of changes per day is not very large. If the modified files are large, they will be copied completely without replacing the previous versions.

The backup process with rsync can be divided into the following steps:

1. A list of files on the redundant server and in the storage is compiled, metadata (permissions, modification time, etc.) or a checksum (when using the --checksum key) are read for each file.
2. If the metadata of the files differ, then the file is divided into blocks and a checksum is calculated for each block. Blocks that differ are uploaded to storage.
3. If a change was made to the file during the checksum calculation or transfer, its backup is repeated from the beginning.
4. By default, rsync transfers data via SSH, which means that each block of data is additionally encrypted. Rsync can also be run as a daemon and transfer data without encryption over its protocol.

More detailed information about the operation of rsync can be found on the official website.

For each file, rsync performs a very large number of operations. If there are a lot of files on the server or if the processor is heavily loaded, then the backup speed will be significantly reduced.

From experience, we can say that problems on SATA disks (RAID1) start after about 200G of data on the server. In fact, everything, of course, depends on the number of inodes. And in each case, this value can be shifted both in one direction and in the other.

After a certain line, the backup execution time will be very long or simply will not work out in a day.

In order not to compare all files, there is lsyncd. This daemon collects information about changed files, ie. we will already have their list ready for rsync in advance. However, it should be taken into account that it gives an additional load on the disk subsystem.

Differential backup

At differential During a backup, every file that has changed since the last full backup is backed up each time. Differential backup speeds up the recovery process. All you need is the latest full and latest differential backup. The popularity of differential backup is growing, as all copies of files are made at certain points in time, which, for example, is very important when infected with viruses.

Differential backups are performed, for example, using a utility such as rdiff-backup. When working with this utility, the same problems arise as with incremental backups.

In general, if a full search of files is performed when looking for a difference in data, the problems of this kind of backup are similar to those with rsync.

We would like to separately note that if in your backup scheme each file is copied separately, then it is worth deleting / excluding files you do not need. For example, these might be CMS caches. Such caches usually contain a lot of small files, the loss of which will not affect the correct operation of the server.

Full backup

A full copy usually affects your entire system and all files. Weekly, monthly and quarterly backups mean creating a complete copy of all data. This is typically done on Fridays or over the weekend when copying a large amount of data does not affect the operation of the organization. Subsequent backups, which run Monday through Thursday until the next full backup, can be differential or incremental, primarily to conserve time and space on the media. Full backups should be done at least weekly.

Most related publications recommend that you perform a full backup once or twice a week, and use incremental and differential backups the rest of the time. There is merit in such advice. In most cases, a full backup once a week is sufficient. It makes sense to execute it again if you do not have the opportunity to update the full backup on the storage side and to ensure the correctness of the backup copy (this may be necessary, for example, if for one reason or another you do not trust the scripts you have or backup software.

In fact, a full backup can be divided into 2 parts:

1. Full backup at the file system level;
2. Full device-level backup.

Consider their characteristic features using an example:
[email protected]:~# df -h Filesystem Size Used Avail Use% Mounted on /dev/mapper/komarov_system-root 3.4G 808M 2.4G 25% / /dev/mapper/komarov_system-home 931G 439G 493G 48% /home udev 383M 4.0K 383M 1% /dev tmpfs 107M 104K 107M 1% /run tmpfs 531M 0 531M 0% /tmp none 5.0M 0 5.0M 0% /run/lock none 531M 0 531M 0% /run/shm /dev/xvda1 138M 22M 109M 17 %/boot

We will only reserve /home. Everything else can be quickly restored manually. You can also deploy a server with a configuration management system and connect our /home to it.

Full backup at the file system level

Typical representative: dump.

The utility creates a "dump" of the file system. You can create not only full, but also incremental backups. dump works with the inode table and "understands" the structure of files (thus, sparse files are compressed).
Dumping a running filesystem is "silly and dangerous" because the filesystem can change while the dump is being created. It must be created from a snapshot (a little later we will discuss the features of working with snapshots in more detail), an unmounted or frozen file system.

Such a scheme also depends on the number of files, and its execution time will increase with the growth of the amount of data on the disk. At the same time, dump is faster than rsync.
If you need to restore not the entire backup, but, for example, only a couple of accidentally corrupted files), extracting such files using the restore utility may take too long

Full device-level backup

1. mdraid and DRBD
   In fact, RAID1 is configured with a disk / raid on the server and a network drive, and from time to time (according to the frequency of backups) additional disk synchronizes with the main drive/raid on the server.

   The biggest plus is speed. The duration of the synchronization depends only on the number of changes made in the last day.
   Such a backup system is used quite often, but few people are aware that the backups obtained with its help can be incapacitated, and here's why. When disk synchronization is complete, the backup disk is disconnected. If, for example, we have a DBMS running that writes data to the local disk in batches, storing intermediate data in the cache, there is no guarantee that they will end up on the backup disk at all. At best, we will lose some of the mutable data. Therefore, such backups can hardly be considered reliable.

2. LVM + dd
   Snapshots are a great tool for creating consistent backups. Before creating a snapshot, you must flush the cache of the FS and your software to the disk subsystem.

For example, with one MySQL it would look like this:
$ sudo mysql -e "FLUSH TABLES WITH READ LOCK;" $ sudo mysql -e "FLUSH LOGS;" $ sudo sync $ sudo lvcreate -s -p r -l100%free -n %s_backup /dev/vg/%s $ sudo mysql -e "UNLOCK TABLES;"

* Colleagues tell stories how someone's "read lock" sometimes led to deadlocks, but in my memory this has never happened.

DBMS backups can be created separately (for example, using binary logs), thereby eliminating the time-consuming cache flush. Or you can create dumps in the repository by running a DBMS instance there. Backing up different DBMS is a topic for separate publications.

You can copy a snapshot using resume (for example, rsync with a patch for copying block devices bugzilla.redhat.com/show_bug.cgi?id=494313), you can block by block and without encryption (netcat, ftp). You can transfer blocks in a compressed form and mount them in storage using AVFS, and mount a partition with backups via SMB on the server.

Compression eliminates transmission speed, bandwidth congestion, and storage space issues. But, however, if you do not use AVFS in storage, then it will take you a lot of time to restore only part of the data. If you use AVFS, you will encounter its "dampness".
An alternative to block compression is squashfs: you can mount, for example, a Samba partition to the server and execute mksquashfs, but this utility also works with files, i.e. depends on their number.

In addition, creating a squashfs consumes a lot of RAM, which can easily lead to a call to oom-killer.

Safety

You need to protect yourself from the situation when the storage or your server is hacked. If the server is hacked, then it is better that the user who writes data there does not have the rights to delete / change files in the storage.
If the storage is hacked, then it is also desirable to limit the rights of the backup user on the server to the maximum.

If the backup channel can be eavesdropped on, then encryption is needed.

Conclusion

Each backup system has its pros and cons. In this article, we tried to highlight some of the nuances when choosing a backup system. We hope that they will help our readers.

As a result, when choosing a backup system for your project, you need to test the selected type of backup and pay attention to:

• backup time in the current stage of the project;
• backup time in case there is much more data;
• channel load;
• load on the disk subsystem on the server and in the storage;
• time to restore all data;
• recovery time for a pair of files;
• the need for data consistency, especially the database;
• memory consumption and the presence of oom-killer calls;

As backup solutions, you can use supload and our cloud storage.
Readers who cannot leave comments here are invited to our blog.

Tags: Add tags

29.10.2012 Michel Poulet

Database backup is the simplest and cheapest way to keep corporate data safe. Don't trust the false sense of security that comes with commissioning latest system high availability. If all data is virtualized and consolidated, the risks even increase

Michelle Poulet ( [email protected])-magazine editor SQL Server Pro, co-founder of Mount Vernon Data Systems and Six Sigma Uptime.

Most companies that have been in the market for a long time have experienced catastrophic events that could have taken them out of the game, such as a database failure. A database backup is a copy of the data, structures, and security objects contained in a database. Each database should be backed up on its own schedule based on the number of write transactions that occur per day. To minimize losses in the event of a database failure, you should back up all databases used in your enterprise. And in order to make sure that the backups are healthy, you should check their work after the restore operations. At the very least, it is necessary to have copies of the databases suitable for quick recovery, and the recovery operation itself should be worked out and not cause any difficulties.

After employees and customers, companies' most valuable asset is data. It is the responsibility of the database administrator to ensure that the data is preserved so that the databases can be restored even if the data center is completely destroyed. Database backup is the simplest and cheapest way to keep corporate data safe.

Don't trust the false sense of security that comes with putting the latest high-availability system into production. If all data is virtualized and consolidated, the risks even increase. How easy life used to be when a single instance of a database was running on a single computer. Now usually on the server in virtual machines Oh dozens of instances of SQL Server are running, which, in the event of a physical server failure, will all fail at the same time. If the funds allow, you can create a failover cluster of virtual machine hosts on different physical servers. If high availability is needed, this is usually done. But even such a fault-tolerant system can be vulnerable in the event of, say, a fire, flood, or earthquake. Backups are still needed. At the same time, the creation of backup copies is entrusted to a limited circle of people. For more information on who can back up, see the sidebar "Who can back up?".

How often a database is backed up depends on how long it takes to restore from a backup. The more frequently a database is backed up, the faster the restore will take. The backup and restore schedule can be configured individually for each database. The type of reservation also depends on the size of the database and the number of transactions performed per unit of time. The main types of backups are full, journal, and incremental. See the sidebar "Database Recovery Models" for more information about recovery modes, and the SQL Server backup commands are described in the sidebar "Standard Backup Commands."

Full redundancy

The full redundancy strategy is the easiest to understand and implement. At the end of each working day (or any other period of time that you can designate), a full database backup procedure is simply launched (Figure 1). You do not need to perform a separate log backup and do not need to use Extra options. File management in this backup mode also does not require special attention, as this is a single full backup file. Restoring from a full backup is also very simple: you just need to restore from a single file. Using full backups - a good choice for organizations with insufficiently experienced IT staff.

A full backup is most suitable for "small" databases - that is, databases that can be backed up within the allotted time. When SQL Server performs a full database backup, it first saves all extents to disk (an extent is eight consecutive pages, each 8 KB in size). SQL Server then backs up the transaction log so that any changes to the database that may have occurred during the backup time are also stored in the full backup file.

If you only perform a full backup, then in the event of a system crash, some data may be lost - primarily changes made since the last backup. If the frequency of database updates is low, for example, only high-speed bulk operations are performed, then you can schedule a full backup immediately after bulk data updates, in which case the data can be considered secure enough.

Full redundancy is not suitable for production systems that are updated quite intensively. When using a full backup, if a restore is necessary, you will have to re-perform all transactions and bulk data loads that were made after the backup was taken. If the last full backup turns out to be corrupted, you will need to take the previous backup to restore and again manually make sure that all transactions that have been performed since the creation of this backup have been applied.

To perform a full database backup, run the following code:

BACKUP DATABASE AdventureWorks TO DISK = 'E:\SQLdata\BACKUPS\AdventureWorks_FullDbBkup.bak'WITH INIT, NAME = 'AdventureWorks Full Db backup', DESCRIPTION = 'AdventureWorks Full Database Backup

The DISK parameter specifies the target backup file. You can back up to disk or to tape (in this case, to disk). Before starting a backup, make sure that the backup folder exists. In most cases, backing up to disk is much faster than backing up to tape, but the cost of disk space is much higher. For an additional layer of protection, you can back up to disk and then save the backup to tape. The WITH INIT option specifies that the backup file should be overwritten. This method is suitable if a Windows backup is performed after every database backup. NAME is the name of the backup, up to 128 characters. If you don't specify a name, the name field will be left blank. DESCRIPTION - a more complete and detailed description that can help, for example, after a long period of time to find out what kind of backup it is and why it was created.

To fully restore the database, run the following command:

RESTORE DATABASE AdventureWorks FROM DISK = 'E:\SQLdata\BACKUPS\AdventureWorks_FullDbBkup.BAK' WITH RECOVERY, REPLACE

WITH RECOVERY instructs SQL Server to roll back any pending transactions that might be in the transaction log and leave the database running. REPLACE means overwriting any existing file with the same name. See the sidebar "Replacing the Database" for more information on this.

When using a full backup strategy, you must monitor the size of the transaction log file. A full backup does not purge the transaction log of inactive entries. If you are only performing a full database backup, you should follow this operation with a cleanup log file backup. To do this, use the TRUNCATE_ONLY setting, as in the command below:

BACKUP LOG AdventureWorks WITH TRUNCATE_ONLY

If set to TRUNCATE_ONLY, no log backup is actually performed, it is a directive for SQL Server to create a checkpoint, clean up inactive items, and reduce the size of the log file. Later versions of SQL Server have removed this setting, but you can use the mode instead. easy recovery to allow SQL Server to automatically purge the transaction log of inactive items.

Full Backup with Logging

If any loss of data during restore is unacceptable, a full backup strategy with log addition can be used. This method will prevent data loss; it is suitable for frequently updated databases. While this strategy increases the complexity of operations and maintenance, the overall time spent on backing up a database is reduced.

Figure 2 shows an example schedule for a full backup with log retention—a weekly full backup on Sundays, and a transaction log backup every following day until the next Sunday when a full backup is performed again. A journal backup saves all changes made since the previous journal backup. In the planning scheme under consideration, daily changes are saved.

Unless otherwise specified, after a log backup is complete, inactive entries in the log are "deleted" (in effect, they are marked for overwriting). When you run the BACKUP LOG command, you can add the NO_TRUNCATE or COPY_ONLY options so that log entries are not changed when you back up. But we do not recommend using these options unless you know for sure what you might need them for.

SQL Server 2005 has a tail-log backup mode, that is, backing up after a database crash if the transaction log has not been corrupted. This mode backs up the latest transactions since the last log backup. For more information about this mode, see the sidebar "What are tail-log backups."

Using the full recovery model provides a relatively simple restore procedure and is the preferred option if you are doing a full backup with a journal. This restores the latest full backup, then sequentially restores the existing logs in chronological order (in the order they were created), and finally restores the tail of the log. This strategy is suitable for production systems, especially if they are transactional and with few bulk operations.

If your database has regular bulk updates, it may make sense to use a bulk logged recovery model. Because the individual records included in the bulk operation are not logged in this case, this approach reduces the overhead of SQL Server logging. Although you can see a noticeable performance increase when performing bulk operations, you risk losing data during recovery if the original data for rerunning bulk operations is not available at the time of recovery. When using the simple recovery model, a log backup is also not possible, because in this case, the log is truncated before the checkpoint.

To perform a full log backup, you must first back up the entire database, as in the example below:

BACKUP DATABASE AdventureWorks TO DISK = 'E:\SQLdata\BACKUPS\AdventureWorks_FullDbBkup.bak' WITH INIT, NAME = 'AdventureWorks Full Db backup', DESCRIPTION = 'AdventureWorks Full Database Backup'

And then you should perform a log backup using the command:

BACKUP LOG AdventureWorks TO DISK = 'E:\SQLdata\BACKUPS\AdventureWorks_TlogBkup.bak' WITH NOINIT, NAME = 'AdventureWorks Translog backup', DESCRIPTION = 'AdventureWorks Transaction Log Backup', NOFORMAT

The WITH NOINIT option in the last command specifies that the backup file should be written in append mode to existing carrier, disk or tape. In this case, all transaction log backups will be written to the same file one after the other. NOFORMAT instructs the backup process to save any header information that may be contained in headers on the backup disks. This is the default, and explicitly specifying this setting is optional, but useful as a self-documenting operation.

To restore from a full backup or a full backup with history, follow the steps below.

1. If the database is online, restrict access to it by switching the access mode (in the properties window) to RESTRICTED_USER. Thus, only members of the db_owner database group and members of the dbcreator and sysadmin server groups will be allowed access to the database.
2. Fix the bug that caused the database to crash.
3. If possible, apply all backed up transaction logs with the NORECOVERY option.

To back up the tail of the log, run the command:

BACKUP LOG AdventureWorks TO DISK = 'E:\SQLdata\BACKUPS\AdventureWorks_TaillogBkup.bak' WITH NORECOVER

To fully restore from a full backup, you must first restore the database files using the command:

RESTORE DATABASE AdventureWorks FROM DISK = 'E:\SQLdata\BACKUPS\AdventureWorks_FullDbBkup.bak' WITH NORECOVERY

The NORECOVERY option tells SQL Server that partial transactions should be left as they are and should not be attempted to be rolled back. Subsequent restores of the transaction logs will restore the data that allows these partial transactions to complete. Using the NORECOVERY option leaves the database in a non-working state. Immediately following a full restore, all transaction log backups with the NORECOVERY option must be restored, as shown below:

RESTORE LOG AdventureWorks FROM DISK = 'E:\SQLdata\BACKUPS\AdventureWorks_TlogBkup.bak' WITH NORECOVERY

Finally, restore the final fragment with the RECOVERY option:

RESTORE LOG AdventureWorks FROM DISK = 'E:\SQLdata\BACKUPS\AdventureWorks_TaillogBkup.bak' WITH RECOVERY

A full recovery strategy with log recovery is not absolute protection. If one of the log backups becomes corrupted, recovery will only be possible up to the point before the corrupted log. For example, suppose you run a weekly full backup on Sundays and that you run log backups Monday through Saturday. If Tuesday's backup is corrupted, then only Monday's data can be restored: the risk of data integrity damage from applying Wednesday's transactions to Monday's data is unlikely to be justified. And restoring the final fragment will also do nothing.

Full plus differential redundancy

In cases where an additional level of assurance is required, delta backups can be added to the schema along with log backups. This strategy is appropriate for transactional databases that are frequently written to, where data loss during restore is unacceptable, and administrators prioritize fast restores.

A differential backup is cumulative—it includes all data and structures that have changed since the last full backup, regardless of when the last full backup was performed or how many times a differential backup has been performed since. Assume that a full backup was performed on Sunday and a differential backup was performed every day, as shown in Figure 3. Monday's differential backup will contain all changes made on Monday, Tuesday's differential backup will contain Monday's and Tuesday's changes, and Wednesday's differential backup will contain Monday's changes. , Tuesday and Wednesday, etc.

Figure 3. Scheduling differential backup jobs

Restoring a differential backup usually takes less time than restoring a full backup plus logs because restoring a single differential backup is faster than restoring a chain of logs. Saving a differential backup is done with the command:

BACKUP DATABASE AdventureWorks TO DISK = 'E:\SQLdata\BACKUPS\AdventureWorks_DiffDbBkup.bak' WITH INIT, DIFFERENTIAL, NAME = 'AdventureWorks Diff Db backup', DESCRIPTION = 'AdventureWorks Differential Database Backup'

To restore a database from a differential backup, complete the following steps.

1. If the database is online, restrict access to it by switching the access mode (in the properties window) to RESTRICTED_USER. This will allow access to the database only to members of the db_owner database group and members of the dbcreator and sysadmin server groups.
2. Back up the tail of the log.
3. Fix the error that caused the database crash.
4. Restore a full backup with the NORECOVERY option.
5. Restore the latest available differential backup with the NORECOVERY option.
6. Perform a tail-log backup restore with the RECOVERY option.

To restore a differential backup (performed after restoring a full backup), enter the command:

RESTORE DATABASE AdventureWorks FROM DISK = 'E:\SQLdata\BACKUPS\AdventureWorks_DiffDbBkup.bak'WITH NORECOVERY

Then restore the tail log with the RECOVERY option using the command above.

Differential redundancy provides more high level data integrity than just redundant logs. If the latest differential backup is corrupted, you can restore the previous differential backup while maintaining data integrity.

Combination strategy

If it's not practical to rerun transactions to restore the last day's operations, you can perform full backups on Sunday, differential backups every night thereafter, and transaction log backups Monday through Saturday mornings and evenings, as shown in Figure 4. If Friday evenings with base If data goes into trouble and Thursday's differential backup is corrupted, you can restore to the environment's differential backup and then apply Thursday's and Friday's logs. Thus, the database will be restored to the very moment of failure. For a more detailed discussion of this issue, see the sidebar "How to restore a database to a point in time."

To reduce the risk of data loss, you should stick to a mixed strategy that includes full backup, log backup, and differential backup, although this mix of methods adds some complexity to the backup strategy and backup management. You should also consider how much data you can afford to lose after a database failure and recovery. Using full recovery strategies or a bulk-logged model instead of simply restoring incurs more transaction log file overhead and results in large files backups, but provides a higher degree of data safety.

Alternative Redundancy Strategies

Backups in SQL Server are not limited to full, delta, and transaction logs. More advanced strategies, including backing up files or groups of files, a partial backup strategy, and backing up only by copying.

Database access during backup and restore

Reservation SQL databases Server is an online process, all stored in SQL server data available during the backup operation. Database modification operations, INSERT, UPDATE and DELETE statements are available in the same way as data selection (SELECT). During a backup, you cannot change the structure of the database or file structure– ALTER DATABASE, ADD FILE, or SHRINKFILE statements cannot be executed during a backup. If the database is enabled auto start shrinking the database file (auto-shrink), there may be a conflict during the backup. So, if during the backup process the automatic reduction of the database file starts, then both operations may fail. The operation that starts first will acquire the lock on the file, and the next operation will have to wait for the lock to be released. If the first operation releases the lock, then the second operation starts. If the blocking timeout of the first operation occurs, the second operation will fail. This approach may seem wrong from the point of view of the execution of the second operation, which is forced to wait for a failure, and only after it will issue a failure. But given that the work of the second operation depends on the success of the first, if the first operation failed, the second operation does not make sense. To prevent this problem, disable automatic shrinking of the database file before performing a backup.

In most cases, restoring a SQL Server database is a stand-alone operation during which users cannot access the database. When using SQL Server 2005 Enterprise Edition with the full recovery model, partial restores and non-primary filegroup restores are online by default. Parts of the database that should not be restored, such as write-only file groups, may be available to users for the duration of the restore operation. Read/Write filegroups are available unless they have been taken offline for recovery. This feature is very useful for large databases running 24x7x365. Additional information can be found in the SQL Server 2005 BOL documentation, "Performing Online Restores" (http://msdn.microsoft.com/en-us/library/ms188671.aspx), and also in the sidebar "Why can't a database restore be performed online" .

Summing up

Data is essential to business, so securing it is one of the most important tasks. Data backup plays a key role in this process. The first step in ensuring continuous access to data is to create a system of regular database backups and test restores. While creating new base data should be scripted for backup and restore immediately. SQL Server provides a variety of backup and restore capabilities that can be tailored to your specific database needs.

Who can make a reservation?

Database backup is available to a limited circle of people. Permission is granted by default to members of certain groups system administrators servers and database roles db_owner and db_backupoperator. When using backup devices, disks or tapes, you need to pay attention to who owns and what permissions are set. SQL Server must be able to read and write to the device. If the account under which SQL Server is running does not have access rights to the device, you will only be aware of this if the backup or restore operation fails. The sp_addumpdevice stored procedure that adds the backup device entry to the system tables does not perform file-level permission checking.

You can specify a password for the backup set. In this case, you must also enter a password when restoring the database. Password protection is an optional measure, which, by the way, is considered unreliable. Password protection is used to prevent data recovery by unauthorized persons who are unaware of the company's backup/restore policies. Since the password does not encrypt the data, this measure will not prevent the backup data from being read using special tools. In addition, the password does not protect against overwriting or deleting the backup file.

Database Recovery Models

The recovery model setting determines how much of the data can be recovered in the event of a database crash. You can set your own recovery model for each database, depending on how much data loss you're willing to accept. To install the database recovery model with using SQL Server Management Studio (SSMS), click right click database, open the Properties window, go to the Options page, and select the desired redundancy model from the drop-down list.

There are three types of recovery models: full, simple, and bulk-logged. The full recovery model makes the most use of all the features of the transaction log and allows you to restore the database from a high degree accuracy at a given point in time. All operations such as data transactions, database structural changes, operating instructions such as transaction completion or cancellation, large objects, and bulk operations are logged. The transaction log is replenished until the transaction log is backed up.

The simple recovery model minimizes the use of the transaction log and allows you to restore the latest full database backup. As with the full recovery model, all transactions (except for some batch operations) are kept in the log. Unlike the full recovery model, SQL Server automatically purges the log of unused items. Because of this, you cannot take transaction log backups when using the simple recovery model.

The bulk-logged recovery model occupies an intermediate position between the "extreme" full and simple recovery models. While the name bulk-logged might suggest that bulk operations are logged, they are actually only partially logged. During bulk operations, which often involve adding a large number of records in a short amount of time, SQL Server sets a bit flag on each affected database extent, but the inserted records are not actually added to the log file. During a subsequent transaction log backup, SQL Server checks this flag and writes to the transaction log backup the database extents themselves that were modified by the bulk operation, in addition to the normal insert and delete records. Thus, a log backup in a bulk-logged recovery model contains the results of performing bulk operations, rather than the individual transactions that actually took place.

Using the bulk-logged recovery model provides the same completeness as the full recovery model, but without the additional overhead that comes with backing up all bulk data inserts. However, there are risks associated with using the bulk-logged recovery model. If the bulk operation's original data is lost between backups, it will not be possible to fully restore the database. Also, it is not possible to restore the database to a point in time from a tail-log backup - attempting to perform a restore will fail.

Although the full recovery and bulk-logged recovery models involve higher transaction log activity and a larger backup file size, this is offset by more complete data recovery in the event of a database failure.

Standard Commands for Redundancy

SQL Server 2005 and SQL Server 2000 have two commands to do essentially the same thing - DUMP and BACKUP (that is, DUMP DATABASE or BACKUP DATABASE and DUMP LOG or BACKUP LOG). The DUMP command has been around since SQL Server 6.5, when backing up a database simply meant copying the database in the state it was in before the backup operation began. At the same time, changes in the database that could have occurred after the start of the backup were not included in the backup.

Starting with version 7, SQL Server can perform a true "live" backup, which means that changes made after the backup process has started are written to the transaction log and stored in the backup file. Thus, a backup is a "snapshot" of the database at the time the backup operation was completed. The DUMP command is retained for backwards compatibility, but Microsoft does not recommend its use on newly developed systems. Someday this command will be deprecated and the developers will have to get rid of it in those snippets program code where it is still in use.

For those who have always been a close watcher of SQL Server database backups and eager to learn what's new in SQL Server 2005, you should continue to keep a close eye on backups: SQL Server 2005 does not have the familiar DBCC REPAIR command. The "replacement" for this command is DROP DATABASE.

Database replacement

When restoring a database to a new server, use the REPLACE option, which disables normal security checks and allows existing databases to be overwritten even if their name differs from the name of the database being restored. For example, suppose you have taken a backup of database D, located on server A. This backup must be restored on server B. First, an empty staging database should be created on server B, the name and size of the staging database being irrelevant. Next, you need to restore base D with the REPLACE option on server B on top of the newly created staging base. If the restore is to be performed back to server A, to its original location, the REPLACE parameter is not required. By default, a database restore operation performs built-in security checks, such as when a database restore cannot normally be performed on top of another existing database. Similarly, restoring a database backed up in full or bulk journaled backup mode is prohibited if there is no tail-log backup.

If you need to recover a database that for one reason or another was not backed up at the tail end of the log (for example, because of a corrupted transaction log backup file), then restoring in REPLACE mode may be the only way to successfully restore. Another example where the REPLACE option is needed is if a production database backup needs to be restored in a test/development environment. Even when the database names in production and development are the same, they are different databases from SQL Server's point of view.

What are tail-log backups

Tail-log backup is a new backup mode in SQL Server 2005. This mode appends transaction log records to the backup that have been added since the log file was last backed up. When you are trying to restore a database to the point of failure, back up the tail-fragment before starting the restore. You do not need to back up the last one if you are going to restore the database to the point before the last transaction log backup, or if you are moving the database from one server instance to another, or if you are overwriting the database. It is possible that the transaction log is corrupted, in which case a tail-fragment backup cannot be performed, and the restore will have to be performed without it.

How to restore a database to a state at a given point in time

There might be a situation where you need to perform a database restore because of code that was executed in error—for example, someone mistakenly deleted a table in a production database, or forgot to include a WHERE clause in a DELETE clause. In such cases, it is required to restore the database to the state before the moment when the erroneous code was executed.

Recovery is a set of operations that bring the database into a consistent state. To restore a database to a specific point in time, you must perform a full restore or a bulk-logged restore. The simple recovery model causes the transaction log to be truncated to a checkpoint without the ability to redo-undo the action (redo-undo) and without the ability to recover to the state at a given point in time.

Performing recovery operations followed by "redo/undo changes" consists in restoring data to its original state at a specific, user-specified point in time - by the name of the completed transaction or by the sequence number in the log. The bulk-logged recovery model has an additional limitation: point-in-point recovery is only possible if no bulk operations have taken place since the previous log backup. In other words, a successful point-in-time restore requires that the sequence of log backup files be contiguous.

Recoverable point-in-time data must be contained in a transaction log backup. When restoring a log, you can restore transactions that were completed up to a specific point in time by specifying the point in time using the STOPAT, STOPATMARK, or STOPBEFOREMARK statement.

When restoring a database to a point in time, perform a full backup with the NORECOVERY setting as shown below:

RESTORE DATABASE AdventureWorks FROM DISK = "E:\SQLdata\BACKUPS\AdventureWorks_FullDbBkup.bak" WITH NORECOVERY

Then apply all log backups with installing RECOVERY and specifying the date and time of the required point in time in each RESTORE LOG clause:

RESTORE LOG AdventureWorks FROM DISK = "E:\SQLdata\BACKUPS\AdventureWorks_TlogBkup.bak" WITH RECOVERY, STOPAT = ‘Dec 10, 2007 8:10 PM’

Backing up files/groups of files

This backup strategy is only appropriate if the database consists of multiple files or groups of files. If database size or performance requirements make a full database backup impossible, and if you need to quickly recover in the event of a failure, you should consider file/filegroup backup strategies.
This strategy can be used for SQL Server 2005 or SQL Server 2000, where each operation requires you to specify which files, filegroups, or combinations to back up. However, you should perform a full database backup shortly after creation, followed by regular backups of files or groups of files. If a particular database needs to use the simple recovery model, all read/write files and groups of files must be backed up at the same time. To minimize data loss during recovery, choose either a full recovery model or a bulk-logged recovery model, and include transaction log backup in your strategy.
Restoring a database still means restricting access to the database, but for a shorter time than with a full database restore. During recovery, access is limited only to groups of files currently being recovered.
In the worst case, if you need to restore the entire database and you are using the full recovery model, you will need all transaction log backups since the database was created. In addition, if you need to restore the database to a specific point in time, you will need a full set of transaction log backups.

Partial recovery

Introduced in SQL Server 2005, this strategy is designed for databases that have multiple read-only filegroups and use the simple recovery model. Because this type of database is primarily read-only, full backup and full restore strategies are redundant. However, the fractional standby model can be applied to any type of database.

When performing a partial backup, the primary filegroup, all read/write filegroups, and any specified read-only filegroups are first backed up. Because read-only tables don't change as often, in theory they don't need to be backed up as often as tables that change.

Careful planning is required before setting up partial redundancy. When creating a database, you should create different groups of files, and when creating tables, place them explicitly in the appropriate file groups. For example, database directory tables in a primary filegroup, read-only tables in read-only filegroups, and read/write tables in read/write filegroups.

Partial backups reduce the time it takes to fully restore a database. If the entire database is read-only, then only the primary filegroup will be included in the partial backup, unless otherwise specified. In addition, a partial backup can be used instead of a full backup as the basis for a differential backup. Fractional reservation provides additional features and increases flexibility in choosing a redundancy strategy.

Restoring after a partial backup still restricts access to the database, but for a shorter period of time than with a full database restore - and only for the primary filegroup, read/write groups, and read-only groups that were part of the backup. More detailed information can be found in the SQL Server 2005 Books Online "Partial Backups" http://msdn.microsoft.com/en-us/library/ms191539.aspx.

State backups

Sometimes there is a need to make a reservation for a special task, for example, to create a presentation to demonstrate to a client. However, you do not want the normal order of the files needed to restore the database to be disturbed. In this case, you can take advantage of the possibility of creating a database state backup. Such a copy can be created regardless of what database recovery strategy is used - full, bulk copy, or simple (bulk-copy, or simple).

But state backups should not be part of a recovery strategy. You can create a copy of the state, restore the database from it on the demo laptop, and then safely delete the backup file. Other "normal" backups do not depend on state copies in any way, so state copies will not be required when performing a restore.

The state backup strategy cannot be used as the basis for a differential backup because the creation of a state copy does not update the differential bitmap used to determine which extents to copy and which to keep. In fact, the differential copy procedure does not take into account the copies of the state that have been made, so such copies cannot participate in the differential restore process.

When backing up the database state transaction log, the transaction log is not truncated, unlike a normal backup. The state backup also has no effect on the log chain that is used for full backup with recovery log. State backups are generally not included in the list of log backups when restoring. For more information, see the SQL Server 2005 BOL "State Backups" documentation at http://msdn.microsoft.com/en-us/library/ms191495.aspx.

Why database restore cannot be done online

Backup administrators are often asked why the database is not accessible during a restore. In fact, partial data access is possible depending on the type of recovery being performed. The general rule is that files, groups of files, or pages that are being auto-recovered are taken offline because it is necessary for the recovery operations to complete successfully.

The recovery process typically begins by copying the data, logs, and index pages from the backup media to the location of the database files. Then comes the turn of the re-execution phase - applying the transactions saved in the log to the data saved at the time the database was backed up; this process is often referred to as "retrying changes". These logged transactions represent changes to the database since the last database backup before the crash. SQL Server first copies the data and structural changes to the transaction log and then executes those changes on the actual database. Redoing changes ensures that the changes that were made in the log are applied to the database.

At this stage, the database usually contains pending transactions and the database cannot be used for access. Next, SQL Server 2005 Standard Edition enters the final undo phase, during which all pending transactions are rolled back. After completing this phase, the database is fully restored and ready to go. The Enterprise Edition works a little differently - the database is ready for use immediately after retrying the changes, without waiting for the rollback phase of pending transactions.

Access to files, filegroups, and pages during database recovery and the retry/undo phases of pending transactions is denied because the data that could be retrieved is invalid. Attempting to process "dirty" data can cause problems related to missed and incomplete transactions.

Infrastructure survey

A large number of diverse servers with various operating systems and services installed on them becomes a real problem if it is necessary to implement single system Reserve copy. An infrastructure survey collects information about all the servers and services used by the company, as well as identifying their features and limitations.

Identification of business and IT needs

Before implementing a backup system, you must first determine how critical certain services are. This will allow in the future to develop optimal, in terms of backup, RPO (Recovery Point Objective) and RTO (Recovery Time Objective) values.

Developing an optimal backup plan

At this stage, the information obtained in the course of previous studies is systematized and the optimal values ​​​​of RTO and RPO are determined. Abaq-2000 specialists will help you determine what backup windows are available for each of the services, taking into account the cost of restoration. The service is suitable for companies that have completed any of the two previous stages.

Implementation of backup systems

Deploying servers and/or backup devices

At this stage, the backup plan is agreed upon. Then one or more servers for the RK are deployed, storage systems and / or tape libraries are connected. Agents for RK are installed, if necessary.

Performing backups, troubleshooting issues, and adjusting the backup plan

Setting up a backup system according to the declared characteristics. Performing a backup. Troubleshoot identified issues, such as configuration errors. In serious cases, contacting the vendor, opening requests in the vendor's technical support. Adjusting the backup execution to match the previously approved plan.

Training and Documentation

Optimizing your existing backup system

Examining existing backup servers

Finding out the version of the existing backup, available licenses and used functionality. The service allows you to determine how optimally the backup system is being used.

Policy optimization and backup process

In case of identified shortcomings or errors, the necessary actions are taken to eliminate them. In addition, work is being done to configure the unused functionality of the system. For example, deduplication on the side of the host that is to be backed up. Optimization allows you to reduce the backup window and ensure file recovery.

Creating a Disaster Recovery Plan

The Disaster Recover plan allows you to restore the server or part of it as quickly as possible in the event of a breakdown. The service includes the creation, development and adjustment of the plan.

Training and Documentation

Train the customer's engineers on how to use the backup system to the extent necessary to complete the backup and resolve any issues that arise. Creation of the following documents: explanatory note, administrator instructions and program, as well as test methods. The list of documents can be changed in accordance with the requirements of the customer. Registration can be in any form or according to GOST. Next, the backup system is tested in accordance with the PMI.

1. Regularity. Making backups should be as regular as brushing your teeth in the morning.
2. Examination. Check the backup you just made. It will be very disappointing if, at a particularly tense moment, your lifesaver turns out to be a dummy. Open several files from the archive and make sure they work.
3. Separation. It is better to store backups not in one place, but at least in two. For example, on an external hard drive and in the cloud. After all, disks sometimes fail, and cloud storage may be unavailable at the right time.
4. delimitation. Divide into several clear categories what you are going to store. Data of different importance requires a different approach to archiving.

System solutions

Windows

Windows has a regular backup and restore tool that allows you to save both individual files and an entire image from which you can restore the system in case of failure.

Windows 7

Go to the "Control Panel" by left-clicking on the "Start" button and selecting the appropriate item. In the "Control Panel", select "System and Security" → "Computer Backup" → "Set up Backup".

Next, the system will ask you to specify a location to save the archive. Please note that if you want to back up data from drive C, you will not be able to save it there. To do this, you will have to select another medium, such as a second physical disk, flash drive, DVD, or folder in local network. If you recall the principles of creating a backup, the archive must be stored on a separate medium, and not on the very computer from which the copy was made.

Next, the system will prompt you to automatically or manually select folders for archiving. Click on “Give me a choice” and in the window that opens, check the boxes for the folders you want to save. Click Next → Save Settings and Exit.

Now in the "Backup or restore files" window there is a button "Archive". Clicking on it will start the process of archiving your data.

Recovery follows the same principle. To do this, click on the item "Select another backup to restore files" and specify the one into which the backup was performed.

Windows 8 and above

The built-in File History tool allows real-time archiving. It only requires initial setup to work.

Go to "Control Panel". To do this, click on the "Start" button with the right mouse button and in context menu find the line you want.

As a storage location, select a drive other than the system drive, a USB flash drive, or network folder. Click "Enable".

"File History" will automatically copy the following libraries: "Documents", "Music", "Images", "Videos" - and standard user folders: Windows, "Desktop", "Favorites".

By default, backups are made every hour, but you can change this time, for example, to 10 minutes. However, this will require more disk space. The retention time for each copy can be configured in the Advanced Options menu.

macOS

Time Machine is Apple's standard solution for backing up applications, files and folders, documents, videos, and music.

To work with Time Machine, you will need a third-party data storage, such as a flash drive, an external HDD or network solution.

When connecting external drive Your Mac should be prompted: Should I use it as a backup? Select "Use as a backup drive".

If the window does not appear, the backup drive must be selected manually:

• go to the menu and open time settings machine;
• click on "Select backup disk";
• select the one you want and click on "Use disk".

Backups will be automatically created once per hour, copies per past month- every day, and all-time backups - every week. Do not be afraid that the volume of your hard drive will be small. Time Machine will save only changed information, and old copies will be automatically deleted as disk space fills up.

Android

Android Backup Service

Designed to create backup copies of data Google accounts. With it, you can save:

• data about Wi-Fi networks;
• desktop wallpaper;
• Gmail settings
• applications Google Play;
• language and input settings;
• date and time;
• row settings third party applications.

To create a backup you need:

• open device settings;
• go to "Personal data" → "Restore and reset";
• turn on Data Backup.

To restore data on another device, just log in with your account. To restore the settings of saved applications, go to "Personal" → "Backup and Reset" → "Auto Restore".

Synchronization

Android provides regular tool sync, which allows you to save user contacts installed from the Google Play app, calendar, display settings, languages ​​and input methods, Google Drive data, and settings for some third-party apps. The tool requires a mandatory Google account.

Synchronization in Android is enabled by default. If you want to get the latest backup, do the following:

• open phone settings;
• in the "Accounts and sync" section, select Google;
• check the boxes and click "Synchronize".

The data will automatically be sent to the Google cloud storage. To restore them on another Android device, just connect your account.

You can also synchronize most popular accounts: Skype, Telegram, Viber and VKontakte. To sync photos and images, Android has a built-in google solution photo.

iOS

iTunes

Apple's universal app for getting and playing content. Allows you to locally save data from a device connected to a computer under Windows control or macOS. This is especially handy when you don't have internet access.

To create a copy when iTunes help do the following:

• connect the device to the computer;
• go to the "Devices" tab;
• click Sync.

• photos;
• notes;
• contact list;
• calendar;
• SMS/MMS messages;
• Safari browser;
• access point settings;
• application data;
• view of the main screen.

iCloud

Cloud service for storing user data. Like any cloud, it has two limitations: the need for Internet access and a relatively small (5 GB) amount of free dedicated space.

To save data using iCloud on your device, open Settings → iCloud → Backup and start the process of creating a copy.

Stored in iCloud:

• purchase history in the App Store;
• photos;
• Phone settings;
• application data;
• view of the main screen;
• ringtones;
• voice mail.

Software

Windows

License: commercial software.

Russian language support: There is.

A simple backup solution. Allows you to save both individual files (photos, music or movies) and mail files, for example from Microsoft Outlook or TheBat.

In the main program window, click "Create a new task" → "Create a backup copy". From the catalog tree, select the data you want to save. In our case, this will be the Music folder on the desktop.

Finally, give the task a name and click Finish. Archiving completed.

The same principle applies to data recovery. Select the saved backup, and then specify where you want to restore it.

The trial period for using the program is 30 days. The developers offer to purchase the full basic version for 800 rubles. There are other versions of Handy Backup - Professional and Expert. Their capabilities are much wider and tailored for professional needs, but for our purposes, the Standard version is enough.

License: shareware software.

Russian language support: No.

Another solution for creating backups and recovering lost files. The interface is so simple and clear that even the absence of the Russian language will not be an obstacle.

First of all, choose where to save the data. Let it be removable drive E.

The next step is to specify the data to save. The program offers both a smart choice, where you can mark desktop files at once, system folders"Pictures" or "Videos" and a directory tree. Go to it and save the already familiar "Music" folder.

After clicking on the checkmark, the archiving window will open. On the selected disk, the program automatically creates the Genie TineLine folder, where it places the saved files.

Save and restore features are available in the basic version of Genie Timeline Free. Extended paid versions Genie Timeline Home and Genie Timeline Pro have much more features: sending email notifications, highly secure data encryption, and scheduling. But for saving home files, the Free version is enough.

Genie TineLine has an iOS app with which you can check the status of backups on your computer.

License: commercial software.

Russian language support: There is.

Powerful backup and restore tool. You can store backups not only on physical disks, but also on your own cloud service Acronis. True, for this you will have to subscribe for a year, and the amount of space provided will depend on tariff plan. With a standard subscription, 50 GB is allocated, with the purchase of a premium version - from 1 TB.

Immediately after installation, the program prompts you to choose what data to send to the copy: from the entire computer, from disks and partitions, or individual folders.

Select "Files and Folders" and select the ones you want. Let it again be the "Music" folder on the desktop. Click "OK" and proceed to the storage selection.

Select flash drive E, click "OK" again → "Create a copy". A copy of the Music folder is created on a flash drive.

Acronis has others useful features. For example, "Archive" allows you to free up disk space by compressing large files, and the "Disk Clone" tool creates a complete copy of local disks, which, in the event of a failure, will allow you to restore the original state of the system.

The cost of the program is 2,700 rubles. A standard subscription for a year will cost users 2,400 rubles, an extended one - 5,100 rubles. Mobile applications work in conjunction with the desktop version and are downloaded for free.

macOS

Carbon Cope Cloner

License: commercial software.

Russian language support: No.

A utility for creating a duplicate disc. Support for the Russian language is not provided, but it will not be difficult to understand the interface.

In Source Disk, select the disk you want to copy. In Target Disk, specify the location to store the copy. Start the process with the Clone button.

The free period of using the program is 30 days. After the Carbon Cope Cloner will cost 2,405.65 rubles.

Android

License: shareware software.

Russian language support: There is.

A convenient solution for backing up and syncing apps on Android without requiring root rights. However, for full-fledged work, you will have to install Helium on a computer running Windows, Linux or macOS.

After installing the application on your smartphone, you will immediately receive a notification about the need for a desktop version. For ease of installation and saving time, the program offers to send a link to a user-friendly messenger or by email. From there follow the link to the program website, download and run. Installation in the style of "Next" → "Next" → "OK" is straightforward.

While the program is being installed, mobile app asks to connect the phone to the computer and enable USB debugging.

After receiving notification of successful synchronization, the smartphone can be disconnected from the computer.

Open the mobile app. From the list installed programs select the ones you need and click on the "Reservation" button. Specify where the backup will be stored and wait for the process to complete.

To restore from a backup, go to the "Restore and Sync" tab, specify the location with the copy, select desired applications and click "Recovery".

The basic version of the program is free, the cost of the extended version is 149.86 rubles.

The extended version allows:

• disable ads;
• set scheduled backups;
• enable synchronization between Android devices;
• store data in the cloud.

The application cannot be installed by owners of Motorola devices and some Sony models.

License: shareware software.

Russian language support: There is.

Most popular among Android users application backup tool. Requires root access to the device.

To create a backup copy of one or more applications, open the "Backups" tab, which presents full list installed software. Exclamation mark near the application indicates that a copy has not yet been created for it. The phone icon means that the program is stored on internal memory devices. The SD card icon indicates applications stored on the memory card.

Select an application and click "Save" in the menu that opens.

The backup has been created. Now, if you enter the application again, you can see the "Restore" button.

Titanum Backup supports group work with applications and backups. To do this, go to "Menu" → "Batch actions".

This function allows:

• check backups - both recently created and the whole - for errors;
• make backup copies of all installed applications;
• make backup copies of all system data;
• delete old backups;
• restore all backups;
• restore all system data;
• clear application cache;
• uninstall system or user apps.

The functionality of Titanium Backup is much wider, but for our purposes, the listed features are quite enough.

The extended version of Titanium Backup costs 349 rubles. Its main features:

• creating multiple backups for an application;
• backup data encryption;
• checking all archives;
• batch freezing and defrosting applications;
• synchronization of backups with the cloud.

iOS

iMazing

License: commercial software.

Russian language support: There is.

Compatibility: Microsoft Windows macOS.

Actually this file manager with the possibility of backup. In many ways, it is similar to iTunes, but it is much easier and more pleasant to work in it. You can transfer data both via cable and via Wi-Fi, and iMazing has no limit on the number of connected devices.

When you connect your device to your computer, iMazing automatically makes a backup of it. The function of changing data directly in the saved copy is very useful: the next time you connect, the changed data is instantly synchronized.

The free period is 30 days, after which you will have to pay $39.99 for use on one computer.

License: commercial software.

Russian language support: No.

Compatibility: iOS.

Device backup tool with . Allows you to save notes, contacts, photos, messages, call histories and more.

To create a backup, just select what you want to save and click on the corresponding icon. A copy can be stored on a smartphone, computer, in the cloud, or sent by email.

To restore data, click on the Restore button in the menu on the left side of the screen.

The cost of BackupAZ is $2.99.

iLex

License: free software.

Russian language support: There is.

Compatibility: iOS.

And this one software requires you to have a jailbreak. Free App iLex allows you to save absolutely any data from the device, besides, it does not require a computer to work.

After creating a backup copy, save it where it is convenient for you, and after flashing the device or in case of loss, copy the archive to your phone and restore the necessary information.

Cydia

License: free software.

Russian language support: There is.

To do this, just go to Manage Accounts, enter your account and select Installable Purchases. That's the only way to do this only for purchased applications. Information about free Cydia does not save.

Cloud Solutions

Google Drive

License: shareware software.

Russian language support: There is.

Compatibility:

Allows you to store user data on Google servers, differentiate access rights to files and folders, open access and share them with other Internet users.

The repository includes:

• Google Drive - used to store files;
• Gmail - saves the user's contacts and is a powerful email client;
• Google Photo - automatically finds images on devices and saves them to the cloud.

15 GB is free. For a larger volume, you will have to pay from 2.99 to 299 dollars. Max Volume storage is 30 TB and the file upload is 5 TB.

For free use 2 GB storage available. The cost of 1 TB will be 9.99 euros. Unlimited space can be purchased for 10 euros per month.

Yandex.Disk

License: shareware software.

Russian language support: There is.

Compatibility: browsers, Microsoft Windows, macOS, Android, iOS.

Cloud service of Russian origin, former Yandex.People. Like previous solutions, it allows you to save data in the cloud and share it with other Internet users. Supports synchronization between different devices.

Users are provided with 10 GB free of charge. For an additional 10 GB, Yandex asks to pay 30 rubles, for 100 GB - 80 rubles, while the cost of 1 TB will be only 200 rubles.