stubblef@stl-08sima.army.mil (Glenda Stubblefield) (04/24/91)
I am System Administrator of two Sun SparcStation 1+ running 4.1, we will soon add a Sparc 2. At the present time I am manually doing full-system backups and am doing incrementals through cron each night. The full systems are done in single-user mode, but the incrementals are done in the middle of the night, while in multi-user. I need to develop the means to do automatic backups, both full and incrementals, through cron during off hours. Is there anyone out there who is doing hands-off full-system dumps? Can you tell me what kind of problems you had (if any)? I guess that specifically I'm concerned about shutting down to single-user and then coming back up. I will be dumping the file systems to a 10Gbyte Exabyte drive, so I don't have to worry about changing tapes. I really appreciate any help anyone can give me on this. Glenda Stubblefield stubblef@STL-08SIMA.ARMY.MIL US AMC SIMA St. Louis, MO
mrl@uunet.uu.net (Mark R. Ludwig) (04/29/91)
In article <2593@brchh104.bnr.ca>, stubblef@stl-08sima (Glenda Stubblefield) writes: >I need to develop the means to >do automatic backups, both full and incrementals, through cron during off >hours. I do not know if it is possible to bring the system down to single-user and then back up to multi-user mode in a hands-off fashion, at least on a Sun (I know it *is* possible on DEC's Ultrix, because their Operator Shell program manages to bring the system down to single-user mode and not get killed itself. I assume there is kernel or ``init'' support for this which I also assume is not present in SunOS.) If your requirements include doing *all* filesystems, the above problem precludes a complete, hands-off solution, but I know it *is* possible to do "user" disks without much problem. Several things are important, but paramount are that you must unmount the filesystem (optimally including the NFS clients, if any) to ensure it is quiescent, and run ``fsck -p'' on the filesystem to make sure it's nice and clean before backing it up to tape. The trick to getting NFS clients to unmount the disk(s) is the ``showmount -a'' command which you can use to generate a command you can issue via ``rsh'' on the client to unmount the filesystem. If your users are sloppy and forget to logoff, you need a sentinel to kill them so the decks will be clear by the time you try to unmount the disks. If they have background jobs running, that's another problem. At our site, those jobs get priority, and the backup simply skips the disk(s) it cannot unmount. After the backup finishes, re-mounting the disks on the NFS clients is only simple if all the information is in ``fstab'' so you can issue a command of the form ``mount nfs_server:/filesystem_export_name'' without needing to know the name of the mount point on the client or any mount options. If you use quotas, remember to turn them on again after mounting the disk(s). For completeness, you might want to check the quotas too. (I have yet to understand why, but occasionally quotacheck actually corrects a problem on our Sun-3 disk, even if the system had not crashed since the last quotacheck.) Regarding the ``root'' and ``usr'' filesystems, if your environment is like ours, the only activity of any interest is user mail and system logs. You can copy or ``tar'' those directories to one of the other "user" disks, from which it will be backed up indirectly. I backup the ``root'' and ``usr'' filesystems irregularly, generally after I've done some substantial work to the system configuration. Since ``usr'' is read-only, that one's even easier to manage.
mstgil@sol.acs.unt.edu (Marc Ph. A. J. St.-Gil) (04/29/91)
stubblef@stl-08sima.army.mil (Glenda Stubblefield) writes: >I need to develop the means to >do automatic backups, both full and incrementals, through cron during off >hours. I am doing such a thing. We have 1.7GB of local disk and a 2GB 8mm tape drive. We do the incrementals like you do. On Friday nights we do unattended SABs. Here's the scenario: 1. at 1700 Fri. - cron fires off a shutdown -r timed for 0200 Sat. 2. at 0130 Sat. - cron 'touches' a file called .../do_backup 3. at 0200 Sat. - the reboot occurs 4. at 0200+ Sat. - the rc.boot script checks for the .../do_backup file If it is there, it fires off a the SAB script and finishes re-booting when the script terminates. 5. at about 0300 Sat. - the backup finishes and the system comes the rest of the way up. The only problem I have encountered is that the system can hang waiting for a dead backup if there is no tape in the drive. Therefore, check for the tape being present at the begining of the SAB script. Marc St.-Gil, UNIX Systems Administrator mstgil@{sol,vaxa,vaxb}.acs.unt.edu University of North Texas 817/565-2324 mstgil@{ponder,solo}.csci.unt.edu Academic Computing Services DISCLAIMER: My employers had no idea I was PO Box 13495, Denton TX, 76203 going to say that.
montjoy@nest.ece.uc.edu (Robert Montjoy) (05/01/91)
I have seen a couple of solutions to automated single user dumps. The one I like is to create a file in / somewhere called dumpit(or whatever) and then issue a shutdown command to reboot into single user mode.. When the machine reboots the rc script will check for the exsistance of /dumpit and execute the proper sequence of commands to perform the dump. Finally, the /dumpit file is removed and the machine is rebooted.. The second solution is to umount the directory that is to be dumped and then you can dump.(The only reason you go single user in the first place is to so you can dump a non-active file system).. You dump the file system and when the dump is finished remount.. Thus, allows you to do mutlti-user dumps.. This is a good method when there are a lot of file systems to dump on you do not want the server down for extened period of time.. The biggest problem with this method is that all processes accessing the filesystem on the local machine will have to be killed.. Rob Montjoy - Rob.Montjoy@UC.Edu Computer Engineer - montjoy@ucbeh.BITNET University of Cincinnati - montjoy@babbage.ece.uc.edu Electrical and Computer Enginering - uunet!uceng!rmontjoy