Database Backup to Cloud services claiming they "DE-DEPE" the files. - Forum - OpenEdge RDBMS - Progress Community

Database Backup to Cloud services claiming they "DE-DEPE" the files.

 Forum

Database Backup to Cloud services claiming they "DE-DEPE" the files.

This question is not answered

I'm looking for any input from anyone who has experiences using a cloud backup service which states they only back up the "changes of your files" to the cloud. I know from previous PUG conferences OpenEdge DB's don't de-dupe well. Has anyone had experiece with these companies that say they can de-dupe their data and send it to the cloud and you can recover your files as of that point in time? 

I see the process as follows:

Do a probackup to a file, the backup file gets sent to the service who 1) store a local copy, 2) uploads only the changes since the last copy to the cloud, 3) allows you to recover copy from the cloud to new location or a cloud server. 

The IT department sees this working with all the windows files, exchange server, MSSQL databases etc. But I don't trust the process with everything I've heard and read about a Progress DB. Because all the extents of the DB change when you startup/shutdown, how are they only tracking the changes.

Anyone using a service like this? What are your experiences. PS database is around 600Gig. 

Thanks for any info. 

All Replies
  • Even if all files are changed when you open a OE DB, not every byte in every file is modified. Probably only a few actualy change. I'm no dedup expert, but I know they check "blocks" for changes, whatever a block mean. Let's say the compare 4KB at a time, so they can extract the changes.

    As with any backup solution, the only way to know it is actually working is to go ahead and restore the backup. Restore, check the database and if everything comes out clean, then you know the bytes of the backup file were correct at the time the restore operation read them. After the backup read those bytes they might have been corrupted by whatever corrups backups :)

  • The issue with these backup technologies is that write order is not guaranteed.  OpenEdge, along with other databases, depend on a Write Ahead Logging protocol for crash recovery to work.  This means that data must be written to the Before Image file before it is written to the data storage portion of the database.

    The Data portion is broken into blocks.  Each block has a version number in it.
    The Before Image notes describe changes to these blocks.  For example, a note could say I know how to change block 1234 from version 10 to version 11 by doing X.  The same note knows how to undo that change, being able to reverse the change of version 10 to 11.  The undo of this, would cause the block version to go from 11 to 12.  This makes crash recovery recoverable.

    Crash recovery has 3 phases.  BI Cluster fix-up, Redo, Undo.  There are more, but at a high level these will do.

    Cluster fix-up makes sure the BI Cluster ring is intact.

    The Redo phase makes sure all the Data blocks are up to date.  During redo these notes are replayed.  A note says it can change the block 1234 from version 10 to 11, we read block 1234, it’s at version 10, we apply the change and make it version 11.  Or we read the block 1234 and it’s at version 14, but our note says we can change it from version 10 to 11, so no work needs to be redone here.

    The undo phase is where problems can occur if the Write Ahead Logging protocol is not enforced.  After redo is complete, all open transactions are undone.  To do this the Before Image file is read backwards for any open transactions.  When it finds a note for say block 1234 and it is the change from version 10 to version 11, if it reads the data block and it’s at version 14, then undo will fail as the note does not know what to do.  This means that the data block 1234 was written to disk, or replicated, before the BI note describing the change was written to disk or replicated.  A big NO-NO.

    The only tested and support SAN based replication is EMC SRDF.  There are many products from EMC that are layered on-top of the EMC SRDF technology as well.  Outside of this supported configuration, any SAN based replication or any technology that claims they can do this MUST preserve write order for crash recovery to work.

    I talk to customers and vendors on this subject weekly to try to educate them of why it may and may not work.  I think knowing why it will not work is useful when having these conversations.

    Mike
    -- 
    Mike Furgal
    Director – Database and Pro2 Services
    PROGRESS Bravepoint
    617-803-2870 


  • Mike, if I understood correctly, the dedup processing would occur on backup files, and those don't change after probkup has finished with them.

    So the OP would send a BAK to a service who would store this first BAK entirely. Then on subsequente backups they would only store diffs.

    As long as the service can provide me with a byte-by-byte exact copy of what I send them, I don't really care how they store things. But again, can they? Only way to be sure is to test backups regularly.

  • For data at rest, meaning not part of the active database the technology is fine.  Backups and Archived AI files are files not part of the active database.

    Mike
    -- 
    Mike Furgal
    Director – Database and Pro2 Services
    PROGRESS Bravepoint
    617-803-2870 


  • For backups I wouldn't be terribly concerned about integrity per se.  As Mike says if the data is at rest then it should be fine.  I would have some concerns about how effective the solution is and the operational issues around it.

    - does it really eliminate much data?

    - how much overhead does it take to do that?

    - is it more, or less, impactful than simply zipping the backup files?

    - how about restores?  How long does it take to get you data when you need to restore?

    If they are talking about de-duping the live database on disk I would be very, very worried and insist on a very high level of proof.

    --
    Tom Bascom
    tom@wss.com

  • This would only be 'backing up to the cloud' the progress probackup file (database.BAK).  The BAK file will be copied to a local appliance ("disk to disk" copy), then that appliance dedups and sends the data to the cloud. The appliance is suppose to keep 4-5 days worth of local copies of the data for recover. The could is more for a DR solution that local environment is gone. Other than the overhead of the initial copy, there is no overhead I'm responsible for.

    I haven't even gotten to the real recovery process because I don't believe in the backup dedupe process. The local appliance is suppose to dedupe the local copy before sending it to the cloud.

    I see it working for file based systems, I just don't see it working for a probackup file.