Re: backup strategies
От | Francisco Reyes |
---|---|
Тема | Re: backup strategies |
Дата | |
Msg-id | cone.1180231571.60218.20758.1000@zoraida.natserv.net обсуждение исходный текст |
Ответ на | backup strategies ("Richard P. Welty" <rwelty@averillpark.net>) |
Список | pgsql-general |
Richard P. Welty writes: > a couple of gig, not really all that much. the problem is that there is > an expectation of one or more persons/organizations going through > due diligence on the operation, and i'm not sure that a fuzzy > "somewhere online" file storage service will pass the smell test for > many of them, where as physical tape cartridges stored offsite will > likely make them happy. I think you should worry much more about getting the procedure done right over making somebody happy. Some of the problems with tape systsems, in my humble opinion, are: 1- More often than not there isn't a second tape unit somewhere to use in case the physical location where the tape unit is, becomes unavailable. Having tapes offsite is useless if you don't have a tape unit handy to put the tapes. Also not only you need a tape unit, but you also need whatever program was used to do the backups to tape. 2- If and when the tape unit dies you need to have a backup scheme until you get the unit repaired. 3- Restore tests are usually not done enough to make sure the process is actually working. You would be surprised how often people have a system they believe works.. to only find out at restore time that it had been failing for a long time. I suggest you look into a multi-stage approach. One form of backup tape and a second approach such as a second machine where you usually do restores. Amazon's S3 can also be a good second location. Just today I was taking a glance at python code to use S3 and looked pretty simple. I would, however, encode the data before sending it to S3. Best of luck in whatever method you choose.
В списке pgsql-general по дате отправления: