You won't like this, but "I think" bacula isn't "Novell supported" on SLES 10 SP1 (SLES 9 SP3 and SLES10)
Thank you very much, I'll implement this (or nearly) migration/backup proc. 2007/8/7, David Boyes <[EMAIL PROTECTED]>: > > > I prefer NFS but we don't have it installed. I suppose it's no-cost, > and > > comes with z/OS. > > I *think* it does nowadays, but you'd need to ask someone more familiar > with z/OS packaging. I just configure 'em, I don't license 'em. See your > system programmer. Void where prohibited. 8-) > > > We will store a lot of server's logs in z/linux (topic "file serving") > for > > two weeks, or one month. After we'll migrate and store them in our > > recently > > bought EMC's Centera, for two years max (legal requirement). Then > we'll > > migrate them to tape. > > Another reason to use Bacula. Bacula supports multiple pools for > migration. Set up logrotate as normal, and include the directories where > you store your logs in your normal Bacula backup jobs. Define a disk > pool for the day-to-day backups as the first pool in the chain and use > that for the target pool in the job definition. Define a pool on the > Centera as the next pool in the chain and set up a migration job to move > files older than two weeks or a month from the first pool to the Centera > pool. Define a pool on z/OS NFS disk, and set up a migration job to move > files older than 2 years from the Centera pool to the z/OS NFS pool. Set > up DFSMShsm migration on the z/OS datasets in the NFS pool as ASAP > migration, and you've got the whole ball of wax completely automated and > hands-free. > > > How can I backup the z/VM and the linux resident minidiscs? > > 0) Take a dump of your z/VM IPL volume with regular DDR or ADRDSSU and > put that tape away somewhere safe as an emergency 1-pack system. You > should stick CMSDDR and/or PIPEDDR on a minidisk attached to the > OPERATOR id so they end up on the z/VM IPL volume as part of your > emergency system. Also, make sure MAINT 190 also stays on that volume so > you can get in and use CMS if everything craters. > > 1) Separate your z/VM sysres and CMS-related data on one set of DASD. > Put your Linux guests on a different group of DASD. Do not EVER mix the > two. Keep PAGE and SPOL data on separate DASD from either one. > > 2) Use PIPEDDR or CMSDDR (both from the VM download library at > www.vm.ibm.com/download) to dump the sysres and CMS-related data with > the COMPRESS operand (for CMSDDR, PIPEDDR automagically does that) to > CMS files (one per volume), and write a short exec to VMARC the CMS > files containing the dumps (to protect the record structure) and copy > them to your z/OS NFS area using the CMS NFS client. Migrate to tape > them on the same schedule as you do your Bacula volumes. > > 3) Dump your SPOL data using SPXTAPE occasionally. On a system with few > or no CMS users, this data changes rarely, so you don't have to do this > very often (once a month is usually sufficient) -- note that this is the > only piece which you need an actual real physical tape drive to perform. > PAGE data is volatile, so you don't really have to care about those > packs other than to know they're there and provide a similar amount of > space in case of a disaster. > > 3.5) Use minidisks for your Linux installs that start at cyl 1, not 0, > and are 1 cylinder short of the end of the volume. Wastes a little disk > space, but lets you easily restore them 2nd level if you need to. > > 4) Back up your Linux guests with Bacula the same way I described for > your log data. The only exception is your Bacula backup server guest, > which needs to be dumped along with the z/VM and CMS data after it is > shut down and logged off. If you have to restore from bare metal, you'll > restore your IPL volume from the DDR or ADRDSSU tape, IPL, create some > SPOL and PAGE volumes with ICKDSF, format and label a volume for the > Bacula server guest, then restore the Bacula server from the CMSDDR or > PIPEDDR dump. You then IPL the Bacula server and use it to restore > everything else. > > 5) Make an IPLable emergency tape for your version of Linux as a safety > net just in case something doesn't restore correctly and you need to > boot Linux from tape and rerun zipl to re-establish boot blocks on a > minidisk. You don't absolutely have to have the very latest, but > something reasonably close (usually the same major release) is a Good > Idea. > > ---------------------------------------------------------------------- > For LINUX-390 subscribe / signoff / archive access instructions, > send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or > visit > http://www.marist.edu/htbin/wlvindex?LINUX-390 > ---------------------------------------------------------------------- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
