Os Backups
- Thread starter Mike
- Start date
os backup (or primitive backup) drawbacks -
main drawback that it's offline only because you need to turn off the database to backup otherwise it will be corrupt
some other drawbacks, several times larger in size because there are no incremental backups and you're copying extents which are partially full.
of course no advanced stuff like restore to any point in time and warm spare replication.
progress backsups drawbacks -
you need to learn howto use the probkup and prorest (and rfutil for after images) command line utils instead of cp or copy
you may want to check the backup system in the baksys/ directory, in the standard libraries project at the oehive.org.
the backup system exports and saves the .st file as part of every backup (and can use the .st file in restoration).
the backups are archived as .zip files (backups that are older than a requested time period are deleted).
the backups are saved as weekly full backups and daily incrementals.
supports after imaging.
supports log files and email alerts and reports (including warning and error notifcations like insufficient disk space).
supports restoration including restoration to point in time.
compatible with unix/linux and windows, version 9 and higher.
hth
main drawback that it's offline only because you need to turn off the database to backup otherwise it will be corrupt
some other drawbacks, several times larger in size because there are no incremental backups and you're copying extents which are partially full.
of course no advanced stuff like restore to any point in time and warm spare replication.
progress backsups drawbacks -
you need to learn howto use the probkup and prorest (and rfutil for after images) command line utils instead of cp or copy
you may want to check the backup system in the baksys/ directory, in the standard libraries project at the oehive.org.
the backup system exports and saves the .st file as part of every backup (and can use the .st file in restoration).
the backups are archived as .zip files (backups that are older than a requested time period are deleted).
the backups are saved as weekly full backups and daily incrementals.
supports after imaging.
supports log files and email alerts and reports (including warning and error notifcations like insufficient disk space).
supports restoration including restoration to point in time.
compatible with unix/linux and windows, version 9 and higher.
hth
tamhas
ProgressTalk.com Sponsor
I might add that the Progress backup accesses the database per the structure of the database. Thus, if there are any problems with that structure, you find out about them. This is not true of an OS backup. It is quite reasonable to do a Progress backup to disk and then an OS backup of the Progress backup to some other storage medium, e.g., for archiving or moving off site.
cj_brandt
Active Member
Progress created a couple items to help with OS backups - proquiet and ai sequence.
We use OS backups with proquiet to backup large databases that would take probkup several hours to complete.
You can / should restore databases taken with OS backups so you can ensure your backup strategy is working.
We use OS backups with proquiet to backup large databases that would take probkup several hours to complete.
You can / should restore databases taken with OS backups so you can ensure your backup strategy is working.
we have several databases that are approximately 60gb
and it doesn't take us more than 15 minutes to do a full backup, maybe 1 minute to do an incremental backup and 15 minutes to restore.
we're using openedge 11, rhel 6 and modest hardware.
and it doesn't take us more than 15 minutes to do a full backup, maybe 1 minute to do an incremental backup and 15 minutes to restore.
we're using openedge 11, rhel 6 and modest hardware.
TheMadDBA
Active Member
When your databases get above 1TB... probkup becomes much less useful and OS backups become the realistic choice. If your database is 200GB or smaller probkup is the sane choice.
If they would only multithread (or vastly speed up) probkup it would be a much better option for larger databases.
If they would only multithread (or vastly speed up) probkup it would be a much better option for larger databases.
what about incremental backups?
do you need a full backup every day?
btw are you saving images, blobs etc. in the database? 1 terabyte of data is extreme.
do you need a full backup every day?
btw are you saving images, blobs etc. in the database? 1 terabyte of data is extreme.
TheMadDBA
Active Member
Incremental backups in OE take about as long as full backups and are almost useless when it comes to restoring.
No images, clobs or blobs in the database. I agree that 1TB is extreme for most OE shops... but virtually nothing for a large business Multi TB databases are extremely common these days. I personally know of a few OE databases that are more than 3TB in size.. I assume there are more out there.
In other DB technologies (Oracle, DB2, SQL Server, etc) I have worked with databases in excess of 10TB. Of course they all handle backups and restores much better than OE so we use the vendor provided backups. They all multi thread and track block changes so that incremental backups actually run very quickly. Its just a matter of large databases being the norm and not a rarity like they are in OE.
No images, clobs or blobs in the database. I agree that 1TB is extreme for most OE shops... but virtually nothing for a large business Multi TB databases are extremely common these days. I personally know of a few OE databases that are more than 3TB in size.. I assume there are more out there.
In other DB technologies (Oracle, DB2, SQL Server, etc) I have worked with databases in excess of 10TB. Of course they all handle backups and restores much better than OE so we use the vendor provided backups. They all multi thread and track block changes so that incremental backups actually run very quickly. Its just a matter of large databases being the norm and not a rarity like they are in OE.
TomBascom
Curmudgeon
CJ & MadDBA certainly know what they are doing and have special situations. They do not qualify as "usually".
Mike does not know what he is doing -- Mike should use probkup. If he were to trust his database to OS backups he would certainly be putting the data and his job at risk. He should not think about OS (or 3rd party tool) backups as anything other than a way to get royally screwed up.
Mike does not know what he is doing -- Mike should use probkup. If he were to trust his database to OS backups he would certainly be putting the data and his job at risk. He should not think about OS (or 3rd party tool) backups as anything other than a way to get royally screwed up.
mollyfud
Member
As someone working in Techsupport for a very long time, this statement is partially right. You should test your backup strategy whether using OS or Probkup. I've had enough production systems down where an untested backup strategy means the situation was a lot worse then it could of been if the customer had know there was issues with their backup process/backup files. Most of these are with probkup. I was once told if your not testing your backups you're not actually backing up!
HTH
Ryszard Musielak
Member
I know there are tons of anwers here, but Mike seems to be beginning his DBA job, correct? Maybe some short answers from me.
1. If someone dropped a table by accident you don't want to restore the whole OS with your database to restore one table. Hence it's best
that you have a database backup as a seperate entity possibly stored in a seperate folder.
2. Many databases run 24/7 and you use a hot/online backups. OS tools like "copy" or "cp" will not be able to backup database blocks
as they may be in use. Oracle will recommend "rman", in SQL-Server you create a "Management task" to backup your DB.
3. The backup tool know what your database is made up of, so no need to list the files, the backup tools will know which files to backup. OS will
not know, nor will a VM tool.
4. If you want to clone your database all you need to do is transfer just the DB backup file, not the whole OS to another location.
5. You can backup your database as part of the OS, but you must be sure that your backup tool can read open DB files. VM tools seem to know
a lot, but you run a risk that if VM backs up your DB files incorrectly your DB restored will be corrupt. Hence it's a good practice to have
your DB backed up on a seperate filesystem/partition or media like disk or tape.
6. OS systems will not be able to detect DB block corruption. Don't know about Progress, but many DB backup tools can do that.
I use Oracle's dump or something called "dbverify" to scan DB files for corruption.
7. Your system is made up of not only DB's, but also programs, system accounts, tons of flat files, etc. You don't always want to restore all of that.
Drawbacks? Depends on the sizes of your databases and the amount of downtime you can have to restore your system.
Overall it's better to have more than 1 backup strategy. Backing up the OS that
has already a DB backup included is not a bad option, many DB backup systems can use compression.
Restoring one 10GB database will be quicker than restoring the whole OS.
Ryszard Musielak
Member
Ah, here's another reason to run a Progress backup and not to use OS commands to perform the task:
Progress KB - Checking your database for corruption when using OS backups
Although you can still perform sanity checks on your database using other tools:
Progress KB - What tools / utilities can I run to check the integrity of a database or check for corruption?
Progress KB - Checking your database for corruption when using OS backups
Although you can still perform sanity checks on your database using other tools:
Progress KB - What tools / utilities can I run to check the integrity of a database or check for corruption?
