|
I have some questions about backup. I hope someone can help me understand some of the different backup types. In the documentation (SQL Anywhere 16) it is stated that: "Typically, a backup uses a combination of full and incremental backups. The frequency of each backup type depends on the type of data that you are protecting. You should also validate your backups to ensure that they can be used for recovery." But when I am looking at the different types of backup and recovery this makes me wonder... both on image and archive backup the documentation says (Database rcovery) "You must not have any incremental backups of the transaction log that need to be applied as part of the recovery process." ok then I would interpret this that you can not then apply an incremental backup, so you can not mix incremental backups with image or archive backup So then it is "only" the dbbackup that you can use both full and incremental backup? Then if you use live backup and the secondary computer loses contact with the "main" computer what happends (when the main computer and the database there is online, not down)? What is the proper thing to do, so you do not "break" anything in this situation? |
|
Step 1: Ignore any and all discussions of "Archive Backup". Unless you use tape drives or other archaic storage media, you will never be creating or restoring from an archive backup. Step 2: Ignore any and all discussions of backup and restore based on simple operating system COPY commands. Those operations require you to shut down the database before creating what is called an "offline backup"... it is a perfectly viable technique, but not really useful in most production environments. Step 3: For the time being, ignore discussions of "Live Backup" until you understand the basics of image backups, both full and incremental log versions thereof. Live backup is a sophisticated failover technique that isn't really a substitute for local backups, it's more of an early version of High Availability mirror databases... which itself is not a substitute for backups. Step 4: Ignore the exhortation "You must not have any incremental backups of the transaction log that need to be applied as part of the recovery process." It appears in exactly three locations in the Help; two are discussions of Archive Backups (see Step 1 above) and the third is a discussion of offline COPY backups (see Step 2 above). Step 5: Study and understand full and incremental image backups. I suggest this article: Demonstrating Backup, Validation and Restore ...it may seem daunting at first glance, but it is A LOT LESS DAUNTING than trying to recover a database in an emergency without a thorough understanding of how things work. See also: Backup is easy, recovery is hard...
I know about step one. So no worry there... I have already ruled out step two. So no worry there either I am interesting in Live backup because our database can not be down for any longer period of time, I am investigating both live bakup and High availibility (and Read only scale out) for this purpose also. Step 4, well in the documentation about Restoring from an image backup it says "You must not have any incremental backups of the transaction log that need to be applied as part of the recovery process." and it is this that makes me wonder how I am supposed to make a full (image)backup with incremental backup and be able to resore it? And if you want to have Live backup how are you suppose to be able to make full backup on the server(dbbackup)? Because if you look at the documentation you can not use option -l (live logging) and then create a image backup on the server (-s option) So I am a little confused... I will look into the article you linked to, perhaps I can find some answers there If someone can/wants to clarify this to me please do so...
(09 Jan '14, 02:55)
M G
I agree that the sentence "You must not have any incremental backups of the transaction log that need to be applied as part of the recovery process." sounds misleading. This doc page has been changed compared to the v12 version. That version's doc page seems more appropriate:
Each restoring from an incremental backup would usually mean to restore the database from the last available full backup and restoring the last incremental log (if you have not truncated/renamed it after the full backup) or restoring all log files created from the time of the full backup (if you have renamed/truncated them).
(09 Jan '14, 03:17)
Volker Barth
Replies hidden
FWIW, I have left a DCX comment on the v16 doc page...
(09 Jan '14, 03:25)
Volker Barth
I second Breck's suggestion to leave live backups out of the discussion until the "basics" are well understood. Nevertheless, to clarify: "dbbackup -s" does a server-side backup whereas dbbackup usually makes client-side backups. So you can still make full backups client-side (just omit -s), and that's usually reasonable with a live backup: If you perform a full or incremental backup (which might truncate/rename the active log leading to a truncated live log as well), you usually want to have the backup files available on the "live backup site" in order to enable a fast "failover". Therefore it surely makes sense to do the backup on the client-side directly.
(09 Jan '14, 03:39)
Volker Barth
|
