备份选项 [英] Backup Options
问题描述
大家好，
我很感谢以前的帖子提供的所有帮助。很高兴有这样一个知识渊博的团队可以帮助我们。
我已经把你以前的所有建议都铭记在心并升级了我们的
DB / 2系统到8.2。
我们的DB / 2 8.2系统托管在洛杉矶的数据中心。我们的总部位于
Portland。
我们目前的数据库大小为18 GB。
我们一直在每天晚上对DB进行完整的离线备份。
我们的流程如下：
1.完成数据库的离线备份后，我们将它转发到
波特兰用于非现场存储和在备用机器上使用如果需要
。
2.期间离线备份，一套完整的日志文件
每两小时就会到达波特兰。
因此，从理论上讲，如果在洛杉矶的DB下来，我们可以恢复所有
数据，当然已经记录，除了最近2小时
的交易价值。
这是问题所在。这一天不再冗长到足以将DB
备份和所有日志文件ftp到Portland。可用的窗口已经变得很小了。
有没有办法我们可以更有效地做到这一点，从而增加了
窗口的有效大小？
在远程位置备份数据库的最有效方法是什么？
然后将备份文件传输到 ;家用"办公室？
我们希望数据库在未来一年内翻倍。
最后一个问题。
我们还计划实施HADR。我们认为这可以解决这个
备份问题，因为当主服务器在洛杉矶时，我们会在波特兰有
的辅助服务器。我们认为我们可以备份服务器本地的数据库。但是，我们已经读过备用数据库不支持备份
操作。这种抛出
我们一条曲线。有没有办法备份备用服务器？如果是这样，这可能会解决我们的整个难题。
感谢您的帮助。
John
johnm写道：
我们的流程如下：
1.之后数据库的离线备份已完成，我们将其FTP到波特兰进行异地存储，并在需要时在备用机器上使用。
2.在离线备份期间，一套完整的日志文件每两个小时就会向波特兰发送一次。
因此，从理论上讲，如果洛杉矶的数据库发生故障，我们可以全部恢复
数据，当然已经记录，除了最近2小时值得交易。
这是问题所在。这一天不再冗长到足以将DB
备份和所有日志文件写入Portland。可用的窗口变得太小了。
有没有办法可以更有效地做到这一点，从而增加窗口的有效尺寸？
您是否尝试过压缩备份（使用COMPRESS选项
或传输之前（使用gzip或bzip2）？
另外，你不需要每晚都发送完整的备份。只需发送
的日志文件，这应该足以保持备用服务器
in您可以每周转发一次完整备份。
Ian
尝试使用delta''它们节省了大量的时间和空间。
-R-
你没有说明FTP链接一个显而易见的选择是
增加网站之间管道的大小。正如之前的
响应所述;压缩也会有所帮助。我也读过关于 案件
两个远程办公室之间假设的高速连接结束了
在中间某处有一个t1部分。当发现这个时;
运营商重新路由以提供适当的带宽。今天的ADSL
服务通常以t1的速度接收，但只有10％或更少的
发送。
一种历史悠久且经常可行的技术是备份到便携式媒体和隔夜复制到远程位置。隔夜费用
需要权衡
传输数据所需的通信链路费用。
Phil Sherman
johnm写道：大家好，
我感谢以前的帖子提供的所有帮助。很高兴有这样一个知识渊博的小组可以帮助我们。
我已经把你以前的所有建议都铭记在心并升级了我们的
DB / 2系统到8.2。
但是，我的备份时间和备份窗口大小仍有问题。
我们的DB / 2 8.2系统托管在洛杉矶的数据中心。我们的总部位于波特兰。
我们目前的数据库大小为18 GB。
我们每天晚上都在对数据库进行完整的离线备份。
我们的流程如下所示：
1.数据库的离线备份完成后，我们将其FTP到
Portland以进行异地存储并在备用机器上使用
需要出现。
2.在离线备份之间，每两个小时就会向波特兰提供一套完整的日志文件。
因此，从理论上讲，如果洛杉矶的数据库发生故障，我们可以恢复所有已经记录的数据，除了最近2小时的交易价值。
<这是问题所在。这一天不再冗长到足以将DB
备份和所有日志文件写入Portland。可用的窗口变得太小了。
有没有办法我们可以更有效地做到这一点，从而增加窗户的有效尺寸？
在远程位置备份数据库的最有效方法是什么？然后将备份文件传输到主页。办公室？
我们希望数据库在未来一年内增加一倍。
最后一个问题。
我们还计划实施HADR 。我们认为这样可以解决这个备份问题，因为当主服务器在洛杉矶时，我们会在波特兰拥有辅助服务器。我们认为我们可以备份服务器本地的数据库。但是，我们已经读过备用数据库不支持备份操作。这种抛出我们的曲线。有没有办法备份备用服务器？如果是这样，这可能会解决我们的整个难题。
感谢您的帮助。
John
Hello All,
I appreciate all of the help with my previous posts. It''s nice having such a
knowledgeable group to draw upon for help.
I have taken all of your previous suggestions to heart and have upgraded our
DB/2 system to 8.2.
However, I still have a problem with backup times and backup window size.
Our DB/2 8.2 system is hosted at a data center in LA. Our main office is in
Portland.
Our current DB size is 18 GB.
We have been taking a full offline backup of the DB every evening.
Our process looks like this:
1. After the offline backup of the DB is completed, we are FTPing it to
Portland for offsite storage and for use on a standby machine should the
need arise.
2. During the period between offline backups, a complete set of log files
are ftp''d to Portland every two hours.
Therefore, and theoretically, if the DB in LA goes down, we can recover all
data, that has been logged of course, except maybe for the last 2 hours
worth of transactions.
Here is the problem. The day is no longer lengthy enough to ftp the DB
backup and all of the log files to Portland. The available window has become
just too small.
Is there a way we can do this more efficiently thereby increasing the
effective size of our window?
What is the most efficient way of backing up a DB at a remote location and
then transferring the backup files to the "home" office?
We expect the DB to double in size over the coming year.
One last question.
We are also planning on implementing HADR. We figured that would solve this
backup problem because while the primary server would be in LA, we would
have the secondary server in Portland. We figured we could then backup both
the DBs local to the servers. However, we have since read that "Backup
operations are not supported on the standby database". This kind of throws
us a curve. Is there a way to backup the standby server? If so, this might
solve our entire conundrum.
Thanks for all of your help.
John
johnm wrote:
Our process looks like this:
1. After the offline backup of the DB is completed, we are FTPing it to
Portland for offsite storage and for use on a standby machine should the
need arise.
2. During the period between offline backups, a complete set of log files
are ftp''d to Portland every two hours.
Therefore, and theoretically, if the DB in LA goes down, we can recover all
data, that has been logged of course, except maybe for the last 2 hours
worth of transactions.
Here is the problem. The day is no longer lengthy enough to ftp the DB
backup and all of the log files to Portland. The available window has become
just too small.
Is there a way we can do this more efficiently thereby increasing the
effective size of our window?
Have you tried compressing your backup (either with the COMPRESS option
or before transmitting (using gzip or bzip2)?
Also, you shouldn''t need to send the full backup every night. Just send
the log files, which should be sufficient to keep your standby server
in sync. You could transfer the full backup once a week.
Ian
Try using delta''s they save a lot of time and space.
-R-
You didn''t state anything about the FTP link. One obvious option is to
increase the size of the "pipe" between the sites. As mentioned in prior
responses; compression will also help. I have also read about cases
where a supposed high speed connection between two distant offices ended
up with a t1 section somewhere in the middle. When this was discovered;
the carrier rerouted to provide the appropriate bandwidth. Today''s ADSL
services usually run t1 speeds for receiving but only 10% or less of
that for sending.
A time-honored and frequently viable technique is to back up to portable
media and overnight a copy to the remote location. The overnight costs
need to be weighed against the cost of the communication link needed to
transmit the data.
Phil Sherman
johnm wrote:Hello All,
I appreciate all of the help with my previous posts. It''s nice having such a
knowledgeable group to draw upon for help.
I have taken all of your previous suggestions to heart and have upgraded our
DB/2 system to 8.2.
However, I still have a problem with backup times and backup window size.
Our DB/2 8.2 system is hosted at a data center in LA. Our main office is in
Portland.
Our current DB size is 18 GB.
We have been taking a full offline backup of the DB every evening.
Our process looks like this:
1. After the offline backup of the DB is completed, we are FTPing it to
Portland for offsite storage and for use on a standby machine should the
need arise.
2. During the period between offline backups, a complete set of log files
are ftp''d to Portland every two hours.
Therefore, and theoretically, if the DB in LA goes down, we can recover all
data, that has been logged of course, except maybe for the last 2 hours
worth of transactions.
Here is the problem. The day is no longer lengthy enough to ftp the DB
backup and all of the log files to Portland. The available window has become
just too small.
Is there a way we can do this more efficiently thereby increasing the
effective size of our window?
What is the most efficient way of backing up a DB at a remote location and
then transferring the backup files to the "home" office?
We expect the DB to double in size over the coming year.
One last question.
We are also planning on implementing HADR. We figured that would solve this
backup problem because while the primary server would be in LA, we would
have the secondary server in Portland. We figured we could then backup both
the DBs local to the servers. However, we have since read that "Backup
operations are not supported on the standby database". This kind of throws
us a curve. Is there a way to backup the standby server? If so, this might
solve our entire conundrum.
Thanks for all of your help.
John
这篇关于备份选项的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
