IP Library Granted Patent US 10,649,858
Granted Patent B2
US 10,649,858 · App. 15/769,312 · Granted May 12, 2020

Synchronization storage solution after an offline event

Inventors: Rick Gene Braddy (Houston, TX); Benjamin Goodwyn (Cypress, TX)
Assignee: SoftNAS, LLC.
G06F11/1464G06F11/07G06F11/0766G06F11/14G06F11/1441G06F11/1469G06F11/1662G06F11/2064G06F11/2082G06F11/2092G06F11/2097G06F11/2048G06F2201/84
View Patent ↗
Loading inventors, assignments & file history…
Monitor This Case
Get email alerts when status or documents change.
Order Certified Copies
Most orders are placed with the USPTO same day — all within 24 business hours.
Order via The Patent Place →
Pre-filled with this patent's details
Quick Facts
Patent No.
US 10,649,858
App. No.
15/769,312
Granted
May 12, 2020
Kind
B2
Abstract

Disclosed are systems and methods of synchronization between a source and a target. The synchronization relationship can be quickly and easily be created for disaster recovery, real-time backup and failover, thereby ensuring that data on the source is fully-protected at an off-site location or on another server or VM, for example, at another data center, a different building or elsewhere in the cloud. Common snapshots available on both the source and target can act as common recovery points. The common recovery points can be used to locate the most recent snapshot in common, between the source and target, to enable a delta sync of all subsequently written data at the source to the target after an offline event.

Claims (74)

1. A method for synchronizing a source server and a target server after an offline event at the source server, the method comprising:

determining an offline event at a source server, wherein the source server and a target server were in a replication relationship prior to the offline event at the source server;

retrieving, from the source server, a list of snapshots;

determining a common snapshot between the source server and the target server;

promoting the target server to new source server, such that the target server receives new write requests subsequent to the offline event and registers the new write requests in a clone of the common snapshot, thereby generating an updating common snapshot clone;

in response to the source server coming back online, identifying un-replicated data that was written to the source server prior to the offline event but was not written to the common snapshot or replicated to the target server;

generating a delta sync snapshot from the updated common snapshot clone generated by the target server and the un-replicated data from the source server;

reverting the source server to the common snapshot; and

replicating the delta sync snapshot from the target server to the source server, such that the target server, acting as new source server, is in a synchronized replication relationship with the source server, acting as new target server.

2. The method of claim 1 , further comprising, in response to determining that the common snapshot could not be located, initiating a full synchronization of the source server and the target server.

3. The method of claim 1 , further comprising:

in response to the source server being online, subsequent the offline event, determining existence of a writable clone; and

in response to the writable clone existing, performing a file update.

4. The method of claim 1 , further comprising:

building a file list, from the source server, subsequent the common snapshot.

5. The method of claim 4 , wherein the file list comprises at least one of:

files modified on the source server and target server;

files modified on the source server and unmodified on target server;

files modified on the source server and do not exist on target server; and

files modified on the source server and unmodified and locked on the target server.

6. The method of claim 4 , further comprising:

processing the file list;

generating a report based on the processing; and

transmitting an alert comprising the report.

7. A system for synchronizing a source server and a target server after an offline event at the source server, the system comprising:

a processor; and

a memory storing instructions which when executed by the processor cause the processor to:

determine an offline event at a source server, wherein the source server and a target server were in a replication relationship prior to the offline event at the source server;

retrieve, from the source server, a list of snapshots;

determine a common snapshot between the source server and the target server;

promote the target server to new source server, such that the target server receives new write requests subsequent to the offline event and registers the new write requests in a clone of the common snapshot, thereby generating an updating common snapshot clone;

in response to the source server coming back online, identify un-replicated data that was written to the source server prior to the offline event but was not written to the common snapshot or replicated to the target server;

generate a delta sync snapshot from the updated common snapshot clone generated by the target server and the un-replicated data from the source server;

revert the source server to the common snapshot; and

replicate the delta sync snapshot from the target server to the source server, such that the target server, acting as new source server, is in a synchronized replication relationship with the source server, acting as new target server.

8. The system of claim 7 , wherein the instructions further cause the processor to initiate a full synchronization of the source server and the target server in response to determining that the common snapshot could not be located.

9. The system of claim 8 , comprising further instructions which when executed cause the processor to:

in response to the source server being online, subsequent the offline event, determine the existence of a writable clone; and

in response to the writeable clone existing, perform a file update.

10. The system of claim 7 , wherein the file update comprises:

building a file list, from the source server, subsequent the common snapshot.

11. The system of claim 10 , wherein the file list comprises at least one of:

files modified on the source server and target server;

files modified on the source server and unmodified on target server;

files modified on the source server and do not exist on target server; and

files modified on the source server and unmodified and locked on the target server.

12. The system of claim 10 , comprising further instructions which when executed cause the processor to:

process the file list;

generate a report based on the processing; and

transmit an alert comprising the report.

13. A non-transitory computer readable medium storing instructions which when executed by a processor cause the processor to:

determine an offline event at a source server, wherein the source server and a target server were in a replication relationship prior to the offline event at the source server;

retrieve, from the source server, a list of snapshots;

determine a common snapshot between the source server and the target server;

promote the target server to new source server, such that the target server receives new write requests subsequent to the offline event and registers the new write requests in a clone of the common snapshot, thereby generating an updating common snapshot clone;

in response to the source server coming back online, identify un-replicated data that was written to the source server prior to the offline event but was not written to the common snapshot or replicated to the target server;

generate a delta sync snapshot from the updated common snapshot clone generated by the target server and the un-replicated data from the source server;

revert the source server to the common snapshot; and

replicate the delta sync snapshot from the target server to the source server, such that the target server, acting as a new source server, is in a synchronized replication relationship with the source server, acting as a new target server.

14. The non-transitory computer readable medium of claim 13 , wherein when the common snapshot is not located the instructions cause the processor to initiate a full synchronization of the source server and the target server.

15. The non-transitory computer readable medium of claim 13 , comprising further instructions which when executed cause the processor to:

in response to the source server being online, subsequent the offline event, determine existence of a writable clone; and

in response to the writable clone existing, perform a file update.

16. The non-transitory computer readable medium of claim 13 , wherein the file update comprises:

building a file list, from the source server, subsequent the common snapshot.

17. The non-transitory computer readable medium of claim 16 , wherein the file list comprises at least one of:

files modified on the source server and target server;

files modified on the source server and unmodified on target server;

files modified on the source server and do not exist on target server; and

files modified on the source server and unmodified and locked on the target server.

18. The non-transitory computer readable medium of claim 16 , comprising further instructions which when executed cause the processor to:

process the file list;

generate a report based on the processing; and

transmit an alert comprising the report.

Assignments (3)
ASSIGNMENT OF ASSIGNOR'S INTEREST Recorded Jun 9, 2021
From: BRADDY, RICK GENE; GOODWYN, BENJAMIN
To: SOFTNAS LLC
Reel/Frame 056479/0769 →
MERGER AND CHANGE OF NAME Recorded Jun 9, 2021
From: SOFTNAS, LLC; SOFTNAS OPERATING, INC.
To: SOFTNAS, INC.
Reel/Frame 056479/0822 →
CHANGE OF NAME Recorded Jun 9, 2021
From: SOFTNAS, INC.
To: BUURST, INC.
Reel/Frame 056526/0312 →
Continuity (2)
Provisional Application 62244961 · Oct 22, 2015
Related Publication 20180307568A1 · Oct 25, 2018
Cited By (1)
US 12,499,125