US-12625721-B2 - Systems and methods for real-time file storage and retrieval

Abstract

The retrieval of files can be facilitated in real-time in the general context of backup and recovery. A processor can receive a request to retrieve a particular volume of data from an object storage database. A virtual volume can be presented to an emulator for creation of a virtual machine representing the particular volume of data. A request can be received to access a particular file from the particular volume of data at a specific point in time. In response to the request to access the file, the data stream can be paused, the particular file can be fetched, and the particular file can be transmitted to the emulator.

Inventors

• Damien Stevens
• Fury Christ

Assignees

• Servosity, Inc.

Dates

Publication Date

20260512

Application Date

20241001

Claims (18)

1. 1 . A computer system, comprising: a data store; and at least one hardware processor in communication with the data store, the at least one hardware processor being configured to: receive a selection of a particular machine of a plurality of machines, wherein the particular machine corresponds to at least one volume; generate a virtual volume for the particular machine; present the virtual volume to a hypervisor; cause the hypervisor to boot an operating system based on the virtual volume; and convert the virtual volume to a standard block device subsequent to merging a stored write request.
2. 2 . The computer system of claim 1 , wherein the at least one hardware processor is further configured to stream files from the at least one volume while the hypervisor is running.
3. 3 . The computer system of claim 1 , wherein the virtual volume is configured to be immutable to the hypervisor.
4. 4 . The computer system of claim 1 , wherein the at least one hardware processor is further configured to: receive a write request from the hypervisor; and store the write request in a write transaction log separate from the virtual volume as the stored write request.
5. 5 . The computer system of claim 4 , wherein the at least one hardware processor is further configured to: determine that streaming to the virtual volume is complete; and merge the stored write request from the write transaction log to the virtual volume.
6. 6 . The computer system of claim 1 , wherein the at least one hardware processor is further configured to: receive a read request from the hypervisor; and prioritize streaming of data for the virtual volume corresponding to the read request.
7. 7 . A method, comprising: receiving, via one of one or more processors, a selection of a particular machine of a plurality of machines, wherein the particular machine corresponds to at least one volume; generating, via one of the one or more processors, a virtual volume for the particular machine; presenting, via one of the one or more processors, the virtual volume to a hypervisor; causing, via one of the one or more processors, the hypervisor to boot an operating system based on the virtual volume; and converting, via one of the one or more processors, the virtual volume to a standard block device subsequent to merging a stored write request.
8. 8 . The method of claim 7 , further comprising streaming, via one of the one or more processors, files from the at least one volume while the hypervisor is running.
9. 9 . The method of claim 7 , wherein the virtual volume is configured to be immutable to the hypervisor.
10. 10 . The method of claim 7 , further comprising: receiving, via one of the one or more processors, a write request from the hypervisor; and storing, via one of the one or more processors, the write request in a write transaction log separate from the virtual volume as the stored write request.
11. 11 . The method of claim 10 , further comprising: determining, via one of the one or more processors, that streaming to the virtual volume is complete; and merging, via one of the one or more processors, the stored write request from the write transaction log to the virtual volume.
12. 12 . The method of claim 7 , further comprising: receiving, via one of the one or more processors, a read request from the hypervisor; and prioritizing, via one of the one or more processors, streaming of data for the virtual volume corresponding to the read request.
13. 13 . A non-transitory computer-readable medium embodying a program that, when executed by at least one computing device, causes the at least one computing device to: receive a selection of a particular machine of a plurality of machines, wherein the particular machine corresponds to at least one volume; generate a virtual volume for the particular machine; present the virtual volume to a hypervisor; cause the hypervisor to boot an operating system based on the virtual volume; and convert the virtual volume to a standard block device subsequent to merging a stored write request.
14. 14 . The non-transitory computer-readable medium of claim 13 , wherein the program further causes the at least one computing device to stream files from the at least one volume while the hypervisor is running.
15. 15 . The non-transitory computer-readable medium of claim 13 , wherein the virtual volume is configured to be immutable to the hypervisor.
16. 16 . The non-transitory computer-readable medium of claim 13 , wherein the program further causes the at least one computing device to: receive a write request from the hypervisor; and store the write request in a write transaction log separate from the virtual volume as the stored write request.
17. 17 . The non-transitory computer-readable medium of claim 16 , wherein the program further causes the at least one computing device to: determine that streaming to the virtual volume is complete; and merge the stored write request from the write transaction log to the virtual volume.
18. 18 . The non-transitory computer-readable medium of claim 13 , wherein the program further causes the at least one computing device to: receive a read request from the hypervisor; and prioritize streaming of data for the virtual volume corresponding to the read request.

Description

CROSS REFERENCE TO RELATED APPLICATION This application is a continuation of U.S. patent application Ser. No. 18/322,081, filed on May 23, 2023 and entitled “Systems and Methods for Real-Time File Storage and Retrieval,” which is a continuation of U.S. patent application Ser. No. 17/668,717, now U.S. Pat. No. 11,698,809, filed on Feb. 10, 2022, and entitled “Systems and Methods for Real-Time File Storage and Retrieval,” which is a continuation of U.S. patent application Ser. No. 16/662,240, now U.S. Pat. No. 11,263,038, filed on Oct. 24, 2019, and entitled “Systems and Methods for Real-Time File Storage and Retrieval,” which is a divisional of U.S. patent application Ser. No. 15/644,104, now U.S. Pat. No. 10,489,186, filed on Jul. 7, 2017, and entitled “Systems and Methods for Real-Time File Storage and Retrieval,” which is a continuation of and claims priority to and benefit of U.S. patent application Ser. No. 14/574,370, now U.S. Pat. No. 9,733,966, filed on Dec. 17, 2014, and entitled “Systems and Methods for Real-Time File Storage and Retrieval,” which claims priority to and benefit of U.S. Provisional Patent Application No. 61/916,849, filed Dec. 17, 2013, and entitled “Real-Time File Storage and Retrieval System Using Object Data to File System Converter,” which are incorporated herein by reference as if set forth herein in their entireties. TECHNICAL FIELD The present systems and methods relate generally to file storage and retrieval. BACKGROUND Non-POSIX (“Portable Operating System Interface”) storage has become a preferable means of storage for large amounts of computer data primarily because of the scalability and reliability of the formats. Unfortunately, data stored in non-POSIX formats is more difficult to access than data stored in POSIX formats. Generally, this difficulty is because non-POSIX storage is not compatible with the typical file data format used by most computers. Additionally, non-POSIX storage generally does not support both read and write functionality (e.g., it is read only of arbitrary data that is not in a files system with directories, files, permissions, etc.). Thus, when a user wants to store a large amount of data in the cloud in non-POSIX format, there are difficulties in later accessing the data quickly. Multimedia streaming, a common non-POSIX use case, has overcome these difficulties because the data in a movie or song generally are presented in a certain order and a buffer can be downloaded accordingly. If, however, the user is attempting to download an entire backup of a system from non-POSIX storage, then these difficulties are readily apparent as there is generally no way to buffer an operating system that does not have files that are presented in a certain order. Thus, the download takes an exceedingly long amount of time, and the user cannot access the backup until the entire file has been downloaded. Therefore, there is a long-felt but unresolved need for a system or method that enables real-time file storage and retrieval from non-POSIX to POSIX formats. BRIEF SUMMARY OF THE DISCLOSURE Briefly described, and according to one embodiment, aspects of the present disclosure generally relate to methods and systems for providing real-time streaming of data in non-POSIX formats to systems in POSIX formats in the general context of system backup and recovery. In one embodiment, the system backup can be stored in non-POSIX format (e.g., object data format or any other arbitrary data format that is not POSIX compliant) and then converted into POSIX format (e.g., file system format with directories, files, permissions, etc. that is generally associated, but should not be limited to, operating systems such as Unix®, Linux®, or Windows®) during the recovery process. In various embodiments, the system backup can be stored in object data format and then converted to a block device and then into file system format during the recovery process. For example, a user can copy and archive an entire system to a remote server and, in the event that a system recovery is necessary, restore the system from the backup in real-time. Usually, these recoveries are necessary when a system crashes or is destroyed or certain files are lost. Thus, when the system crashes, the user can start the restoration process and begin using the system almost instantaneously, instead of waiting for the entire backup to download, which traditionally could take hours or even days. In one embodiment, the user can incrementally back up the system to the cloud instead of backing up the entire system. In various embodiments, the user can use other types of backups including, but not limited to, differential backups instead of backing up the entire system. As will be described in greater detail herein, aspects of the disclosed system include a server and a non-POSIX database. Examples of content that may be backed up include files, folders, drives, operating systems, or combinations thereof. As will be understood