{"id":35493,"date":"2013-10-30T01:57:37","date_gmt":"2013-10-30T01:57:37","guid":{"rendered":"http:\/\/blog.open-e.com\/?p=35493"},"modified":"2025-04-04T06:38:08","modified_gmt":"2025-04-04T06:38:08","slug":"diary-of-an-admin-backup-and-data-replication","status":"publish","type":"post","link":"https:\/\/www.open-e.com\/blog\/diary-of-an-admin-backup-and-data-replication\/","title":{"rendered":"Diary of an admin: Backup and Data Replication"},"content":{"rendered":"

Among many technologies that increase data storage protection, the term \u2018replication\u2019 is used very frequently.<\/p>\n

Replication, as a way of creating an exact data copy between the source storage location and the target location, is often erroneously put into one bag with backup. Despite of the fact that in both cases we can talk about \u2018data copies\u2019 – backup and replication cannot be treated as synonyms.<\/strong><\/p>\n

When you use block or file-based replication, a mirrored copy of the data is created in a location different from the parent data. In case of file-based replication there is an option to keep deleted files on the destination location. Also, a limited versioning can be achieved with file-based replication. It can be done with multiple replication tasks by copying the source data into a few different locations. For example, every Monday the replication task will copy the data to the first sub-directory, Tuesday to the second, etc. With such setup, 7 days behind will be preserved but the disadvantage is significantly much higher storage space required. BTW, this may be fixed with deduplication.<\/p>\n

Depending on the software, the target location can be usually found on the remote computer, on a portable disk connected to the local computer or, in case of file-based replication, just a directory (e.g. a mounted NFS or SMB).<\/p>\n

\"Data<\/a><\/p>\n

Now, let\u2019s analyze three days from the life of an administrator who wants to perform a backup through replication.<\/strong><\/p>\n

\n

Diary of an administrator: Day 1<\/h2>\n

Today, I used replication to create<\/i> a mirrored copy of the data, and now I can enjoy the fact that if my source file fails – I have a copy of all data on the backup server. Unfortunately, on the same day I received a notification from the secretary, Mrs. Christie, that she unintentionally deleted important files. I took it easy because after all, I had the data copy. Imagine my disappointment after I searched for the desired files on the backup server and found nothing. ;-(<\/i><\/span><\/p>\n<\/div>\n

During data replication all data is being synchronized. In the situation described above, the administrator did not find a copy of the deleted files from the source server, because once they were deleted by Mrs. Christie, the absence of those files was also replicated to the target server. In other words, in case of block-based replication , the deletion of the files from the source server also resulted in the removal from the target server. Moreover, in case of block replication, any errors that occur in the hardware layer (e.g. damaged disk) can result in damage of the file system and are replicated to the backup server. In the end, you can accidentally become an owner of two damaged and useless mirrored copies. This situation also applies to the file-based replication, which in case of hardware layer or file system errors means replication of the damaged files. Let’s take a look at the next note from the diary of our unlucky administrator.<\/p>\n

\n

Diary of an administrator: Day 2<\/h2>\n

Thankfully, the company didn\u2019t<\/i> collapse because of my inability to recover the lost files. But today there was yet another disaster. Mrs. Christie from the secretary\u2019s office asked for a copy of her files from two weeks ago. Ugh!<\/i><\/p>\n<\/div>\n

Yes, replication by itself does not perform data versioning, but just simply copies the changes from one place to another. Multiple file versioning is the domain of the traditional backup or snapshot technology. It can be relatively easy to achieve replicated data versioning if we combine replication with one of the technologies (or both). \u00a0For example, when snapshots are performed within a one-hour interval, it is possible to restore your data to the state of the required time. On the other hand, when we use backup combined with replication or\/and snapshots, the leeway tends to expand even more.<\/p>\n

\n

Diary of an administrator:\u00a0 Day 3<\/h2>\n

I was not able to explain to Mrs.<\/i> Christie that I don\u2019t have a copy of files from two weeks ago. She wasn\u2019t happy. On top of that, the main data server gave up together with all the data. So, I swapped the broken master server for the backup server, which contained a previously replicated copy of the data. Everybody breathed a sigh of relief that the data has become available again.<\/i><\/p>\n<\/div>\n

And that is how the story of our administrator ends. Of course, it has been presented in an oversimplified way. Pleased with a \u2018happy end\u2019 of this story, I shall move on to some conclusions.<\/p>\n

Replication can be compared (assuming a constant synchronization) to a kind of RAID 1 network. In case of a failure of one of the replicated servers – replication can protect us from data loss. However, it is not a backup. Nonetheless, we can \u2018arm\u2019 the replicated data during backup performance. Thanks to this, we gain fully operable copies of the data from the server and a mirror copy of all data on two servers.<\/p>\n

In future articles you will be able to read about using simple file-based replication with file versioning.<\/p>\n","protected":false},"excerpt":{"rendered":"

Among many technologies that increase data storage protection, the term \u2018replication\u2019 is used very frequently. Replication, as a way of creating an exact data copy between the source storage location …<\/p>\n","protected":false},"author":4,"featured_media":51322,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"footnotes":""},"categories":[14,29],"tags":[48,86,195],"class_list":["post-35493","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-backup-storage-technology","category-data-protection","tag-admin","tag-backup","tag-data-replication"],"acf":[],"aioseo_notices":[],"_links":{"self":[{"href":"https:\/\/www.open-e.com\/blog\/wp-json\/wp\/v2\/posts\/35493","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.open-e.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.open-e.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.open-e.com\/blog\/wp-json\/wp\/v2\/users\/4"}],"replies":[{"embeddable":true,"href":"https:\/\/www.open-e.com\/blog\/wp-json\/wp\/v2\/comments?post=35493"}],"version-history":[{"count":1,"href":"https:\/\/www.open-e.com\/blog\/wp-json\/wp\/v2\/posts\/35493\/revisions"}],"predecessor-version":[{"id":55116,"href":"https:\/\/www.open-e.com\/blog\/wp-json\/wp\/v2\/posts\/35493\/revisions\/55116"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.open-e.com\/blog\/wp-json\/wp\/v2\/media\/51322"}],"wp:attachment":[{"href":"https:\/\/www.open-e.com\/blog\/wp-json\/wp\/v2\/media?parent=35493"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.open-e.com\/blog\/wp-json\/wp\/v2\/categories?post=35493"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.open-e.com\/blog\/wp-json\/wp\/v2\/tags?post=35493"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}