Patent Publication Number: US-2020278792-A1

Title: Systems and methods for performing storage operations using network attached storage

Description:
CROSS-REFERENCE TO RELATED APPLICATIONS 
     Any and all applications for which a foreign or domestic priority claim is identified in the Application Data Sheet as filed with the present application are hereby incorporated by reference under 37 CFR 1.57. 
     COPYRIGHT NOTICE 
     Portion of the disclosure of this patent document contains material that is subject to copyright protection. The copyright owner has no objection to the facsimile reproduction by anyone of the patent document or the patent disclosures, as it appears in the Patent and Trademark Office patent files or records, but otherwise expressly reserves all other rights to copyright protection. 
     Related Applications 
     This application is related to the following patents and pending applications, each of which is hereby incorporated herein by reference in its entirety: 
     U.S. Pat. No. 6,418,478, titled PIPELINED HIGH SPEED DATA TRANSFER MECHANISM, issued Jul. 9, 2002; 
     U.S. application Ser. No. 09/610,738, titled MODULAR BACKUP AND RETRIEVAL SYSTEM USED IN CONJUNCTION WITH A STORAGE AREA NETWORK, filed Jul. 6, 2000, now U.S. Pat. No. 7,035,880, issued Apr. 25, 2006; 
     U.S. Pat. No. 6,542,972, titled LOGICAL VIEW AND ACCESS TO PHYSICAL STORAGE IN MODULAR DATA AND STORAGE MANAGEMENT SYSTEM, issued Apr. 1, 2003; 
     U.S. application Ser. No. 10/658,095, titled DYNAMIC STORAGE DEVICE POOLING IN A COMPUTER SYSTEM, filed Sep. 9, 2003, now U.S. Pat. No. 7,130,970, issued Oct. 31, 2006; and 
     U.A. Application Ser. No. 10/818,749, titled SYSTEM AND METHOD FOR PERFORMING STORAGE OPERATIONS IN A COMPUTER NETWORK, filed Apr. 3, 2004, now U.S. Pat. No. 7,246,207, issued Jul. 17, 2007. 
     BACKGROUND 
     Field 
     The present invention relates generally to performing storage operations on electronic data in a computer network, and more particularly, to data storage systems that employ primary and secondary storage devices wherein certain electronic data from the primary storage device is relocated to the secondary storage device pursuant to a storage policy and electronic data from the second storage device may retrieved directly or through the primary storage device. 
     The storage of electronic data has evolved over time. During the early development of the computer, storage of electronic data was limited to individual computers. Electronic data was stored in the Random Access Memory (RAM) or some other storage medium such as a magnetic tape or hard drive that was a part of the computer itself. 
     Later, with the advent of network computing, the storage of electronic data gradually migrated from the individual computer to stand-alone storage devices accessible via a network. These individual network storage devices soon evolved into networked tape drives, optical libraries, Redundant Arrays of Inexpensive Disks (RAID), CD-ROM jukeboxes, and other devices. Common architectures also include network attached storage devices (NAS devices) that are coupled to a particular network (or networks) that are used to provide dedicated storage for various storage operations that may be required by a particular network (e.g., backup operations, archiving, and other storage operations including the management and retrieval of such information). 
     A NAS device may include a specialized file server or network attached storage system that connects to the network. A NAS device often contains a reduced capacity or minimized operating and file management system (e.g., a microkernel) and normally processes only input/output (I/O) requests by supporting common file sharing protocols such as the Unix network file system (NFS), DOS/Windows, and server message block/common Internet file system (SMB/CIFS). Using traditional local area network protocols such as Ethernet and transmission control protocol/internet protocol (TCP/IP), a NAS device typically enables additional storage to be quickly added by connecting to a network hub or switch. 
     Hierarchical storage management (HSM) provides for the automatic movement of files from hard disk to slower, less-expensive storage media, or secondary storage. As shown in  FIG. 1 , the typical migration hierarchy is from magnetic disk  10  to optical disk  20  to tape  30 . Conventional HSM software usually monitors hard disk capacity and moves data from one storage level to the next (e.g., from production level to primary storage and/or from primary storage to secondary storage, etc.) based on storage criteria associated with that data such as a storage policy, age, category or other criteria as specified by the network or system administrator. For example, an email system such as Microsoft Outlook™ may have attachments “aged off” (i.e., migrated once an age requirement is met) from production level storage to a network attached storage device by HSM systems. When data is moved off the hard disk, it is typically replaced with a smaller “placeholder” or “stub” file that indicates, among other things, where the original file is located on the secondary storage device. 
     A stub file may contain some basic information to identify the file itself and also include information indicating the location of the data on the secondary storage device. When the stub file is accessed with the intention of performing a certain storage operation, such as a read or write operation, the file system call (or a read/write request) is trapped by software and a data retrieval process (sometimes referred to as de-migration or restore) is completed prior to satisfying the request. De-migration is often accomplished by inserting specialized software into the I/O stack to intercept read/write requests. The data is usually copied back to the original primary storage location from secondary storage, and then the read/write request is processed as if the file had not been moved. The effect is that the user sees and manipulates the file as the user normally would, except experiencing a small latency initially when the de-migration occurs. 
     Currently, however, HSM is not commonly practiced in NAS devices. One reason for this is because it is very difficult, if not impossible, to intercept file system calls in NAS devices. Moreover, there are many different types of NAS devices, such as WAFL by Network Appliance of Sunnyvale, Calif., the EMC Celera file system by the EMC Corporation of Hopkinton, Mass., the Netware file system by Novell of Provo, Utah, and other vendors. Most of these systems export their file systems to host computers such as the common Internet file system (CIFS) or the network file system (NFS), but provide no mechanism to run software on their operating systems or reside on the file system stack to intercept read/write or other data requests. Further, many NAS devices are proprietary, which may require a significant reverse-engineering effort to determine how to insert software into the I/O stack to perform HSM operations, reducing portability of an HSM implementation. 
     Accordingly, what is needed are systems and methods that overcome these and other deficiencies. 
     SUMMARY 
     The present invention provides, among other things, systems and methods for performing storage operations for electronic data in a computer network on a network attached storage device (NAS). Some of the steps involved in one aspect of the invention may include receiving electronic data from a network device for writing to the NAS device; writing the electronic data to the NAS device in a first location (i.e., primary storage); subsequently storing the electronic data to a second location (i.e., secondary storage); and storing a stub file at the first location, the stub file including a pointer to the second location that may redirect the network device to the second location if an access request for the electronic data is received from the network device. In some embodiments, when the NAS device receives an electronic data request from a network device, the operating system of the network device may recognize the stub file as a stub file. In this case, the network device may use the pointer to find the actual location of the stored electronic data, where the electronic data may be accessed and processed over the network by the network device itself. 
     In accordance with some aspects of the present invention, computerized methods are provided for archiving data that is written to a first location in a NAS device to a second location, and storing a stub file at the first location, the stub file having a pointer pointing to the second location, the stub file for redirecting a network device to the second location if a read request for the file is received from the network device. 
     The system may include a NAS device connected to a network. The network may interconnect several network devices, including, for example, several client computers, host computers, server computers, mainframe computers or mid-range computers, all sending file system requests to the NAS. The NAS device may receive the file request from the network devices and process them. 
     An example of a method for processing a request for storing data on the NAS device may include receiving the data from a network device for writing to the NAS device; writing the data to the NAS device in a first location known to the network device; storing the data to a second location; and storing a stub file at the first location, the stub file having a pointer pointing to the second location, the stub file for redirecting the network device to the second location if a read request for the data is received from the network device. In some embodiments, the stub file may be named the same as the data that was stored in the first location before archiving. However, when the network attached storage device provides a read request to read the data, the operating system of the network device may recognize the stub file as a stub file. The network device may then perform the task of following the pointer to the actual location of the archived data, where the data may be read from and processed over the network by the network device itself. This relieves the NAS device from excess processing of the read request, including having to de-migrate the data from secondary storage. 
     Thus, one way to process a read request in accordance with an embodiment of the present invention includes opening the stub file stored in place of the data by the NAS device at a first location, the first location being where the data was stored before the file was archived to a second location by the network attached storage system; reading a pointer stored in the stub file, the pointer pointing to the second location; and reading the data from the second storage location. 
    
    
     
       BRIEF DESCRIPTION OF THE DRAWINGS 
       The invention is illustrated in the figures of the accompanying drawings which are meant to be exemplary and not limiting, in which like references are intended to refer to like or corresponding parts throughout, and in which: 
         FIG. 1  is a diagrammatic representation of basic components and data flow of prior art HSM systems; 
         FIG. 2  is a block diagram of a system constructed in accordance with the principles of the present invention for storing and retrieving electronic data from primary and secondary storage locations; 
         FIG. 3  is a flow chart illustrating some of the steps for performing storage and retrieval operations on electronic data in a computer network according to an embodiment of the invention; 
         FIG. 4  is a flow chart illustrating some of the steps performed when a system application attempts to access electronic data moved from primary storage to secondary storage in accordance with an embodiment of the present invention; 
         FIG. 5  is a flow chart illustrating some of the steps performed when a system application attempts to alter electronic data moved from primary storage to secondary storage in accordance with an embodiment of the present invention; and 
         FIG. 6  is a chart illustrating steps performed in a Solaris-based embodiment of the system shown in  FIG. 2 . 
     
    
    
     DETAILED DESCRIPTION 
     An embodiment of a system  50  constructed in accordance with the principles of the present invention is shown in  FIG. 2 . As shown, system  50  may include a NAS device  100 , a network  90 , network devices  85 , data migrators  95 , primary storage device  102 , secondary storage devices  120  and  130 , storage area network (SAN)  70 , media agent  97 , storage device  140  and storage manager  180 . NAS  100  may be coupled to network  90  which may itself also include or be part of several other network types, including, without limitation, Ethernet, IP, Infineon, Wi-Fi, wireless, Bluetooth or token-ring, and other types. 
     One or more network devices  85  may be coupled to network  90 . Each network device  85  may include a client application, a client computer, a host computer, a mainframe computer, a mid-range computer, or any other type of device capable of being connected in a network and running applications which produce electronic data that is periodically stored. Such data may be sometimes referred to as “production level” data. In some embodiments, a network device  85  may have the ability to generate electronic data requests, such as file requests and system requests to NAS device  100  through the network  90 . 
     NAS device  100  may include, and/or be connected to, a primary storage device  102  such as a hard disk or other memory that provides relatively high-speed data access (as compared to secondary storage systems). Primary storage device  102  may include additional storage for NAS device  100  (which may itself include some internal storage), and may be the first network storage device accessed by network devices  85 . 
     As shown in  FIG. 2 , NAS device  100  may include one or more data migrators  95 , each of which may be implemented as a software program operating on NAS  100 , as an external computer connected to NAS  100 , or any combination of the two implementations. Data migrator  95  may be responsible for storing electronic data generated by a network device  85  in primary storage device  102 , or other memory location in NAS device  100 , based on a set of storage criteria specified by a system user (e.g., storage policy, file size, age, type, etc.). Moreover, data migrators  95  may form a list or otherwise keep track of all qualifying data within network devices  85  and copy that data to primary storage device  102  as necessary (e.g., in a backup or archiving procedure, discussed in more detail below). 
     A storage policy (or criteria) is generally a data structure or other information that includes a set of preferences and other storage criteria for performing a storage operation. The preferences and storage criteria may include, but are not limited to: a storage location, relationships between system components, network pathway(s) to utilize, retention policies, data characteristics, compression or encryption requirements, preferred system components to utilize in a storage operation, and other criteria relating to a storage operation. A storage policy may be stored to a storage manager index, to archive media as metadata for use in restore operations or other storage operations, or to other locations or components of the system. 
     Storage operations, which may generally include data migration and archiving operations may involve some or all of the following operations, but are not limited thereto, including creation, storage, retrieval, migration, deletion, and tracking of primary or production volume data, secondary volume data, primary copies, secondary copies, auxiliary copies, snapshot copies, backup copies, incremental copies, differential copies, synthetic copies, HSM copies, archive copies, Information Lifecycle Management (“ILM”) copies, and other types of copies and versions of electronic data. 
     De-migration as used herein generally refers to data retrieval-type operations and may occur when electronic data that has been previously transferred from a first location to a second location is transferred back or otherwise restored to the first location. For example, data stored on NAS  100  and migrated to in secondary storage and then returned to NAS  100  may be considered de-migrated. De-migration may also occur in other contexts, for example, when data is migrated from one tier of storage to another tier of storage (e.g., from RAID storage to tape storage) based on aging policies in an ILM context, etc. Thus, if it was desired to access data that had been migrated to a tape, that data could be de-migrated from the tape back to RAID, etc. 
     In some embodiments, data migrators  95  may also monitor or otherwise keep track of electronic data stored in primary storage  102  for possible archiving in secondary storage devices  120  and  130 . In such embodiments, some or all data migrators  95  may periodically scan primary storage device  102  searching for data that meet a set storage or archiving criteria. If certain data on device  102  satisfies a set of established archiving criteria, data migrator  95  may “discover” certain information regarding that data and then migrate it (i.e., coordinate the transfer the data or compressed versions of the data) to secondary storage devices, which may include tape libraries, magnetic media, optical media, or other storage devices. Moreover, is some embodiments archiving criteria, which generally may be a subset set of storage criteria (or policies), may specify criteria for archiving data or for moving data from primary to secondary storage devices. 
     As shown in  FIG. 2 , one or more secondary storage devices  120  and  130  may be coupled to NAS device  100  and/or to one or more stand alone or external versions of data migrators  95 . Each secondary storage device  120  and  130  may include some type of mass storage device that is typically used for archiving or storing large volumes of data. Whether a file is stored to secondary storage device  120  or device  130  may depend on several different factors, for example, on the set of storage criteria, the size of the data, the space available on each storage device, etc. 
     In some embodiments, data migrators  95  may generally communicate with the secondary storage devices  120  and  130  via a local bus such as a SCSI adaptor or an HBA (host bus adaptor). In some embodiments, secondary storage devices  120  and  130  may be communicatively coupled to the NAS device  100  or data migrators  95  via a storage area network (SAN)  70 . 
     Certain hardware and software elements of system  50  may be the same as those described in the three-tier backup system commercially available as the Commvault QiNetx backup system from Commvault Systems, Inc. of Tinton Falls, N.J., and further described in application Ser. No. 09/610,738 which is incorporated herein by reference in its entirety. 
     In some embodiments, rather than using a dedicated SAN  70  to connect NAS  100  to secondary storage devices  120  and  130 , the secondary storage devices may be directly connected to the network  90 . In this case, the data migrators  95  may store or archive the files over the network  90  directly to the secondary storage devices  120  and  130 . In the case where stand-alone versions of the data migrators  95  are used without a dedicated SAN  70 , data migrators  95  may be connected to the network  90 , with each stand-alone data migrator  95  performing its tasks on the NAS device  100  over the network. 
     In some embodiments, system  50  may include a storage manager  180  and one or more of the following: a media agent  98 , an index cache  97 , and another information storage device  140  that may be a redundant array of independent disks (RAID) or other storage system. These elements are exemplary of a three-tier backup system such as the Commvault QiNetx backup system, available from Commvault Systems, Inc. of Tinton Falls, N.J., and further described in application Ser. No. 09/610,738 which is incorporated herein by reference in its entirety. 
     Storage manager  180  may generally be a software module or application that coordinates and controls system  50 . Storage manager  180  may communicate with some or all elements of system  50  including client network devices  85 , media agents  97 , and storage devices  120 ,  130  and  140 , to initiate and manage system storage operations, backups, migrations, and recoveries. 
     A media agent  97  may generally be a software module that conveys data, as directed by the storage manager  180 , between network device  85 , data migrator  95 , and one or more of the secondary storage devices  120 ,  130  and  140  as necessary. Media agent  97  is coupled to and may control the secondary storage devices  120 ,  130  and  140  and may communicate with the storage devices  120 ,  130  and  140  either via a local bus such as a SCSI adaptor, an HBA or SAN  70 . 
     Each media agent  97  may maintain an index cache  98  that stores index data system  50  generates during, store backup, migration, archive and restore operations. For example, storage operations for Microsoft Exchange data may generate index data. Such index data may provide system  50  with an efficient mechanism for locating stored data for recovery or restore operations. This index data is generally stored with the data backed up on storage devices  120 ,  130  and  140  as a header file or other local indicia and media agent  97  (that typically controls a storage operation) may also write an additional copy of the index data to its index cache  98 . The data in the media agent index cache  98  is thus generally readily available to system  50  for use in storage operations and other activities without having to be first retrieved from a storage device  120 ,  130  or  140 . 
     Storage manager  180  may also maintain an index cache  98 . The index data may be used to indicate logical associations between components of the system, user preferences, management tasks, and other useful data. For example, the storage manager  180  may use its index cache  98  to track logical associations between several media agents  97  and storage devices  120 ,  130  and  140 . 
     Index caches  98  may reside on their corresponding storage component&#39;s hard disk or other fixed storage device. In one embodiment, system  50  may manage index cache  98  on a least recently used (“LRU”) basis as known in the art. When the capacity of the index cache  98  is reached, system  50  may overwrite those files in the index cache  98  that have been least recently accessed with new index data. In some embodiments, before data in the index cache  98  is overwritten, the data may be copied t a storage device  120 ,  130  or  140  as a “cache copy.” If a recovery operation requires data that is no longer stored in the index cache  98 , such as in the case of a cache miss, system  50  may recover the index data from the index cache copy stored in the storage device  120 ,  130  or  140 . 
     In some embodiments, other components of system  50  may reside and execute on the storage manager  180 . For example, one or more data migrators  95  may execute on the storage manager  180 . 
     Referring now to  FIG. 3 , some of the steps involved in practicing an embodiment of the present invention are shown in the flow chart illustrated thereon. When a network device sends a write request for writing a data to the NAS device, the write request may include a folder, directory or other location in which to store the data on the NAS device (step  300 ). Through a network, the network device may write the data to the NAS device, storing the file in primary storage (and/or NAS) in the location specified in the write request (step  302 ). As shown, after a data migrator copies data to secondary storage (step  304 ) the data migrator may store a stub file at the original file location, the stub file having a pointer pointing to the location in secondary storage where the actual file was stored, and to which the network device can be redirected if a read request for the file is received from the network device, step  306 . 
     Referring now to  FIG. 4 , some of the steps involved in attempting to read certain data that has been migrated to secondary storage media is shown in the flow chart of  FIG. 4 . As illustrated, a network device may attempt to read data that was originally stored at the current location of the stub file at step  400 . The operating system of the network device may read the stub file at step  402  and recognize that the data is now a stub file, and be automatically redirected to read the data from the location pointed to by the stub file at step  404 . This may be accomplished for example, by having the network device follow a Windows shortcut or a UNIX softlink (in Solaris applications). The data may then be accessed by directly reading from the secondary storage location at step  406 . Although this process may cause a slight delay or latency attributable to the redirection, and, in the case of a secondary storage device using cassettes or other library media, may cause additional delay involved with finding the proper media, the delay normally associated with de-migrating the data to primary storage is eliminated. 
     With reference to  FIG. 5 , a flow chart illustrating some of the steps performed when data is edited after being read from archive by a client network device are shown. After the data is read from a secondary storage device and edited (step  500 ), if the network device performs a save operation and issues a write request to the NAS device (and generally speaking, not a save-as operation to store the file in a new location), the data may be stored in the primary storage device at the original location where the data was stored before archiving, replacing the stub file (step  502 ). Depending on the type of file system and configuration of the secondary storage device, the archived data may be marked as deleted or outdated if the secondary storage device retains old copies of files as a backup mechanism (step  504 ). Next, the edited data continues to reside in primary storage until a data migrator archives the edited data to secondary storage (step  506 ) and places a stub file in its place in primary storage (step  508 ). 
     In other embodiments, when a network device issues a save command after the data edited in step  500 , instead of being stored to the stub file location, the data may be stored back to the archive location, leaving the stub file intact, except that if the stub file may keep track of data information, such information may be changed according to the edited data. 
     In an embodiment that stores files that can be read by a network device using the Windows operating system, for example, the data migrator may produce a Windows shortcut file of the same name as the archived file. Other operating systems may provide for use of shortcut files similar to Windows shortcuts that can be used as stub files in the present system, including, for example, Mac OS by Apple Computer, Inc. of Cupertino, Calif. 
     Also, in embodiments which store files that can be read by a network device using Unix type file systems, such as Linux, Solaris, or the like, a softlink is used for re-direction, which is similar to a Windows shortcut. For example, a typical command to create a softlink in Unix systems is as follows: [ 0054 ] In -s /prim ary_storage_location/stubfile/secondary_storage_location/archivefile wherein primary_storage_location is the location in the primary storage device, the stubfile is the name of the stub file containing the softlink, the secondary_storage_location is the location to which the file is archived, and the archivefile is the name of the file stored in the secondary location. 
     In some Unix-based systems, such as Solaris, when a network device needs to read a file, the network directory and drive where the file resides may need to be mounted if the directory and file are not already mounted. When the network device issues a read request to a NAS device to read an archived file in such a system, the Softlink stored in the data&#39;s primary storage location may have been archived to a drive or directory that is not already mounted for file access. 
     One way to resolve this issue of unmounted drives or directories is to trap the read request, either by the NAS device or the network device, to interrupt processing and to mount the drive and/or directory to which the Softlink is pointing to the archived data so the network device may then read the data from the secondary location. 
     However, many Unix file systems do not provide a ready infrastructure to trap an input/output request before the request is usually propagated to the file system. Using Solaris as an example, many Unix systems typically provide a generic file system interface called a virtual file system (vfs). Vfs supports use by various file systems such as the Unix file system (ufs), Unix network file system (nfs), the Veritas file system (vxfs), etc. Similarly, directories in these file systems may need to be mounted on the individual network devices in Unix based systems. Vfs can act as a bridge to communicate with different file systems using a stackable file system. 
       FIG. 6  is a flow chart illustrating some of the steps performed in a Solaris-based embodiment of the present invention, which provides one or more data migrators that each which may include a stackable loopback file system. The stackable loopback file system&#39;s interface may be designed such that if a network device or an application issues a read/write request (i.e., an open( ) request), the stackable loopback file system intercepts the request (step  600 ). The stackable loopback file system may provide a facility to trap calls, such as open, read, write and other typical Unix file operations if the request is for a stub file (step  602 ). If the request is for a non-archived file, (step  604 ) then the stackable loopback file system propagates the normal operations to the underlying file system such as ufs and vxfs, step  605 , and a regular open( ) is performed by the underlying file system. 
     Otherwise, if the request is for an archived file,  FIG. 6  presents some options of three different embodiments to perform the handling of the trapped request, steps  606 A,  606 B or  606 C, after which, the system may redirect the application or restores the file stored at the secondary location to the stub file location, step  608 . Option one, step  606 A, is to override the open( ) operation in the libc.so library with a new open( ) command (i.e. cv_open). This may be used for applications that use libc.so during runtime. For the applications which are using dynamically linkable libraries, if the open( ) operation can be overwritten in libc.so with cv_open keeping intact the existing symbols for the other calls, then this option will work for those applications as well. However, this option may not work for applications which directly open the file in the kernel, such as database applications. Further, this option may not work for the statically linked applications. 
     Option two, step  606 B, involves changing the trap handler for the open( ) system call. Trap handlers are implemented in assembly and are typically specific to the various Unix architectures. Solaris systems usually include a generic trap handler for system calls and other traps and may be implemented, if desired. 
     Option three, step  606 C, may be used for implementing a stackable loopback file system. This option uses a loopback file system that propagates the normal operations to the underlying file System like ufs, vxfs and also provides a facility to trap the required calls. The stackable loopback file system provides the various vfs operations. The stackable loopback file system also provides vnode operations typically used by other file systems. A vnode may be a virtual node comprising a data structure used within Unix-based operating systems to represent an open file, directory, device, or other entity (e.g., socket) that can appear in the file system name-space. The stackable loopback file system provides a mount option to mount the existing file directory to some other location that is used as the secondary location for storing the file. The special mount operation may search through the underlying file system, store the necessary information of the underlying file system, and assign the path as its starting root. Example commands to accomplish this operation follows: 
     
       
         
           
               
               
             
               
                   
                   
               
             
            
               
                   
                 mount_cxfs/etc/etc 
               
               
                   
                 mount_cxfs/etc/tmp/etc_temp 
               
               
                   
                   
               
            
           
         
       
     
     Where/etc/tmp/etc_temp does not appear in a mounted path already. This mount option is used for those file directories, which are not already mounted. 
     One way to implement the additional functionality of stackable loopback file system is to make the stackable loopback file system a loadable module or driver. Unix systems, such as Solaris, usually support file system drivers such as the loadable modules. The stackable loopback file system module may support both normal file system and driver functionalities. The stackable loopback file system driver may use input-output controls (ioctls), which are special request device drivers above and beyond calls to the read or write entry points, to provide the capability to mount the file directories. Vnode operations may simply pass through the driver to the underlying file system, except that read/write/mmap operations are trapped to handle data migration of the relocated files, and performs a lookup operation to resolve recursions of the files mounted to some other location. 
     The driver may be included in the migrator, preferably in an embodiment where the migrator resides on the NAS. The migrator may include a relocate daemon that triggers the data migration for the files to be migrated if user defined policies are met. The relocate daemon may then creates the stub file. A redirect/restore daemon may be triggered by the stackable loopback file system when a stub file is accessed. The restore daemon may mount the drive and/or secondary drive or directory where the file was archived if the drive and directory are not already mounted. The stackable loopback file system may then re-directs the network device to the directory where the file is stored as described above. In an alternative embodiment, after mounting the drive and directory, the file may be restored to the primary location. The driver may generate an event for the restore daemon to complete restoration. Restore daemon may send an ioctl for the completion of the restoration and deletes the stub file. 
     Thus, as can be seen from the above, systems and methods for recovering electronic information from a storage medium are provided. It will be understood that the foregoing is merely illustrative of the principles of the present invention and that various modifications can be made by those skilled in the art without departing from the scope and spirit of the invention. Accordingly, such embodiments will be recognized as within the scope of the present invention. 
     Systems and modules described herein may comprise software, firmware, hardware, or any combination(s) of software, firmware, or hardware suitable for the purposes described herein. Software and other modules may reside on servers, workstations, personal computers, computerized tablets, PDAs, and other devices suitable for the purposes described herein. Software and other modules may be accessible via local memory, via a network, via a browser or other application in an ASP context, or via other means suitable for the purposes described herein. Data structures described herein may comprise computer files, variables, programming arrays, programming structures, or any electronic information storage schemes or methods, or any combinations thereof, suitable for the purposes described herein. User interface elements described herein may comprise elements from graphical user interfaces, command line interfaces, and other interfaces suitable for the purposes described herein. Screenshots presented and described herein can be displayed differently as known in the art to input, access, change, manipulate, modify, alter, and work with information. 
     While the invention has been described and illustrated in connection with preferred embodiments, many variations and modifications as will be evident to those skilled in this art may be made without departing from the spirit and scope of the invention, and the invention is thus not to be limited to the precise details of methodology or construction set forth above as such variations and modification are intended to be included within the scope of the invention. 
     Persons skilled in the art will appreciate that the present invention can be practiced by other than the described embodiments, which are presented for purposes of illustration rather than of limitation and that the present invention is limited only by the claims that follow.