{"id":29927,"date":"2019-10-31T21:32:42","date_gmt":"2019-10-31T18:32:42","guid":{"rendered":"https:\/\/prohoster.info\/blog\/bekap-mne-na-lentu-zapili-rasskaz-ot-pervogo-litsa\/"},"modified":"2019-10-31T21:32:42","modified_gmt":"2019-10-31T18:32:42","slug":"bekap-mne-na-lentu-zapili-rasskaz-ot-pervogo-litsa","status":"publish","type":"post","link":"https:\/\/prohoster.info\/en\/blog\/bekap-mne-na-lentu-zapili-rasskaz-ot-pervogo-litsa","title":{"rendered":"\"Back up to tape for me.\" A first-person account","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

In the previous article<\/a><\/noindex> We told you about the new features in the Update 4 released in January for Veeam Backup & Replication 9.5 (VBR), intentionally not mentioning backups to magnetic tape. A discussion about this area deserves a separate article, as there were indeed many new features.<\/p>\n

\u2013 Guys from QA, will you write an article?
\n\u2013 Why not!<\/p>\n

\""Back
\n
\n<\/a><\/noindex><\/p>\n

Tape Drives in the 21st Century<\/h1>\n

\nData storage on magnetic tapes (cassettes, \"tapes<\/b>\", as we in R&D call them) is not limited to the outdated ZX-Spectrum computer, where one game could load into 48 kb of RAM from a tape recorder<\/a><\/noindex> for several minutes. Over a quarter of a century, the speed and capacity of tapes have increased by 6-7 orders of magnitude. This is not quite a fair comparison, and by Moore's Law<\/a><\/noindex> the standard LTO<\/a><\/noindex> it is not keeping up. Nonetheless, modern technologies allow recording 12 terabytes of data (up to 30 terabytes in compressed mode) on a kilometer-long tape of one cassette, thus, the $160 drive leaves competitors behind in terms of the cost of long-term storage of large amounts of data, even considering the investments in read\/write equipment. Data on such tapes is reliably stored for 15-30 years.<\/p>\n

Let me approach it from another angle. Recently, ransomware<\/a><\/noindex> has hit a new level. They can lie in wait within a large company's infrastructure for weeks and months, and with the emergence of another zero-day vulnerability, they can destroy (not without human help, as big money is at stake) not only all data but also all backups that can be reached. Here\u2019s a fresh example<\/a><\/noindex>, when a company had to pay the ransom. The so-called air gap<\/b>, i.e., physically isolated backups from the infrastructure, have essentially become the only reliable protection against such scenarios. Magnetic tape is one of the timeless solutions.<\/p>\n

\""Back
\n
\nHowever, one specification and technological innovations in iron and barium ferrite from leading manufacturers (IBM, HPE, Oracle, Dell) are not enough for reliable data protection; good software is needed. At Veeam, we have an entire team dedicated to tape backups, with about 10 people analyzing, planning, researching, developing, and testing daily. You might have seen the results of this work in previous articles (one<\/a><\/noindex>, two<\/a><\/noindex>). What has been accomplished over the past year?<\/p>\n

Glossary<\/h1>\n

\nThere comes a choice between freedoms regarding the native language and bureaucratic phrases that complicate readability. I prefer the former, so I apologize in advance if any jargon from the list below is jarring to someone. Here, I will briefly remind you what each term means. <\/p>\n

Experts in VBR can skip this part<\/b>Job <\/b>is the task of backing up. Essentially, the entire VBR is built on jobs. Besides backup and replication, it may also involve copying to tape (backup to tape job). I should mention that restoring from a backup (restore) is also a job, but in this article, the term will specifically refer to backup.<\/p>\n

Storage <\/b>is a historically established name. These are files in the repository <\/b>(repository), which contain backups \u2013 full <\/b>and incremental.<\/b>A single storage can contain one or several virtual machines.<\/p>\n

Chain <\/b>is a sequence of interconnected storages. To restore data from the nth incremental storage, all previous storages from (n-1) to 1 and the full storage referenced by the first incremental are needed.<\/p>\n

Source<\/b>, Target <\/b>are the source and the target. The source is the original entity that the job processes. In the case of backups\/replicas, this is usually a virtual machine in the hypervisor. In the case of tape jobs, the source is the backup job itself (or the files in the case of a file to tape job). The target for backup jobs is the repository where backups are stored. For tape jobs, it is the media pool.<\/p>\n

Media pool<\/b> \u2013 is a pool of media, in our case \u2013 cartridges. A logical container created by the user that contains cartridges from one or several libraries. Thus, a tape job always has a media pool as a target, meaning that data is written not to a specific cartridge or any cartridge in the library, but to a specific set of them. The media pool has a data retention setting, after which the cartridge can be overwritten. Users can create standard and<\/a><\/noindex> GFS pools. Each of these types can now also be WORM or non-WORM, more on this below.<\/a><\/noindex>Media set<\/p>\n

media set<\/b> \u2013 media set<\/a><\/noindex> \u2013 a set of tapes in the media pool that are continuously written to for backups\/files. For GFS pools, media sets are also tied to an interval (for example, yearly), with tapes rotating only within their specific interval.<\/p>\n

Drive<\/b>, changer<\/b><\/a><\/noindex> \u2013 elements of the tape library. The drive reads and rewinds the tape, while the changer is a robot that moves tapes between storage slots, unload slots, and the drive. There are also standalone drives<\/b> (standalone) where a person performs the role of the changer. A correctly installed manufacturer driver on a Windows machine connected to the library is mandatory for the drive; however, we can work with the changer without drivers, using native SCSI.<\/p>\n

<\/p>\n

Tenant to tape. The provider is protected \u2013 clients are protected.<\/h1>\n

\nLet's lay the cards on the table. The most significant feature of our update designed for cloud providers.<\/a><\/noindex>, using VBR in their infrastructure. Development started two years ago. Soon, we realized we wouldn't be able to handle such a serious task by the next release, took a brief pause, and ultimately released the feature in 9.5 Update 4.<\/p>\n

In short, providers now have the ability to copy their clients' backups to tapes using tape jobs in the GFS pool. This offers providers \u2013 who are very important to our hearts and commercial department \u2013 two opportunities:<\/p>\n