{"id":335,"date":"2020-08-18T19:23:47","date_gmt":"2020-08-18T20:23:47","guid":{"rendered":"http:\/\/www.linux-tutorial.info\/?page_id=77"},"modified":"2020-08-22T19:26:18","modified_gmt":"2020-08-22T20:26:18","slug":"this-is-the-page-title-toplevel-168","status":"publish","type":"page","link":"http:\/\/www.linux-tutorial.info\/?page_id=335","title":{"rendered":"Preparing Yourself"},"content":{"rendered":"\nPreparing Yourself<\/title>\n<concept id=\"\" description=\"Problem-solving starts before you have even installed your system.\" \/>\n<p>\nProblem-solving starts before you have even installed your system. Because a\ndetailed knowledge of your system is important to figuring out what’s causing\nproblems, you need to keep track of your system from the very beginning. One\nmost effective problem-solving tool costs less than $2 and can be found in grocery\nstores, gas stations, and office supply stores. Interestingly enough, I can’t\nremember ever seeing it in a store that specialized in either computer hardware\nor software. I am talking about a notebook. Although a bound notebook will do\nthe job, I find a loose-leaf notebook to be more effective because I can add\npages more easily as my system develops.\n<\/p>\n<p>\nWith today’s technology, you don’t need to do things like this with pen and paper.\nThere are any number of software products that provide you with a means of recording this\nkind of information. Plus it can be accessed by anyone anywhere where they have access to a\ncomputer. However, you can carry the notebook with you into every corner of your company,\neven if there is no computer access available.\n<\/p>\n<p>\nIn the notebook I\ninclude all the configuration information from my system, the make and model of\nall my hardware, and every change that I make to my system. This is a running\nrecord of my system, so the information should include the date and time of the\nentry, as well as the person making the entry. Every time I make a change, from\nadding new software to changing <glossary>kernel<\/glossary> parameters, should\nbe recorded in my log book.\n<\/p>\n<p>\nAs we discussed, there are a number of different programs that will show you information about your system. It would be farily straight forward to write a script that collects this information, as well\nas the contents of various configuration files and then\n<\/p>\n<p>\nIn putting together your notebook, don’t be terse with comments like, “Added SCSI\npatch and relinked.” This should be detailed, like, “Added patch for Adaptec AIC-7xxx.\nRebuild and reboot successful.” Although it seems like busy work, I also believe\nthings like adding users and making backups should be logged. If messages\nappear on your system, these, too, should be recorded with details of the\ncircumstance. The installation guide should contain an “installation checklist.”\nI recommend that you complete this before you install and keep a copy of this in\nthe log book.\n<\/p>\n<p>\nSomething else that’s very important to include in the notebook\nis problems that you have encountered and what steps were necessary to correct\nthat problem. One support engineer with whom I worked told me he calls this his\n“solutions notebook.”\n<\/p>\n<p>\nAs you assemble your system, write down everything you can about the hardware\ncomponents. If you have access to the invoice, a copy of this can be useful for\nkeeping track of the components. If you have any control over it, have your\nreseller include details about the make and model of all the components. I have\nseen enough cases in which the invoice or delivery slip contains generic terms\nlike Intel 2400Mhz <glossary>CPU<\/glossary>, cartridge tape drive, and 500GB hard\ndisk. Often this doesn’t even tell you whether the hard disk is\n<glossary>SCSI<\/glossary>, <glossary>IDE<\/glossary>, <glossary>SATA<\/glossary>,\n or what.\n<\/p>\n<p>\nNext, write down all the settings of all the\ncards and other hardware in your machine. The jumpers or switches on hardware\nare almost universally labeled. This may be something as simple as J3 but as\ndetailed as <glossary>IRQ<\/glossary>. Linux installs at the\ndefaults on a wide range of cards, and generally there are few conflicts unless\nyou have multiple cards of the same type. However, the world is not perfect and\nyou may have a combination of hardware that neither I nor Linux developers has\never seen. Therefore, knowing what <em>all<\/em> the settings are can become an\nimportant issue.\n<\/p>\n<p>\nOne suggestion is to write this information on gummed\nlabels or cards that you can attach to the machine. This way you have the\ninformation right in front of you every time you work on the machine.\n<\/p>\n<p>\nAlthough becoming less common with the rise of the Internet, many companies have a “fax back” service\nin which you can call a number and have them fax you documentation of their\nproducts. For most hardware, this is rarely more than a page or two. For\nsomething like the settings on a hard disk, however, this is enough. Requesting\nfaxed documentation has a couple of benefits. First, you have the phone number\nfor the manufacturer of each of your hardware components. The time to go hunting\nfor it is not when your system has crashed. Next, you have (fairly) complete\ndocumentation of your hardware. Last, by collecting the information on your\nhardware, you know what you have. I can’t count the number of times I have talked\nwith customers who don’t even know what kind of hard disk they have, let alone\nwhat the settings are.\n<\/p>\n<p>\nAnother great place to get technical information is\nthe World Wide Web. I recently bought a <glossary>SCSI<\/glossary>\nhard disk that did not have any documentation. A couple\nof years ago, that might have bothered me. However, when I got home, I quickly\nconnected to the Web site of the driver manufacturer and got the full drive\nspecs, as well as a diagram of where the jumpers are. If you are not sure of the\ncompany’s name, take a guess, as I did. I tried <i>www.seagate.com<\/i>, and it\nworked the first time. The worst case is that you need to google for it.\n<\/p>\n<p>\nWhen it comes time to install the\noperating system, the first step is to read the release notes and installation\n<glossary>HOWTO<\/glossary> and any\ndocumentation that comes with your distribution. I am not suggesting reading\nthem cover to cover, but look through the table of contents completely to\nensure that there is no mention of potential conflicts with your\n<glossary>host<\/glossary> adapter or the particular way your video card needs to\nbe configured. The extra hour you spend doing that will save you several hours\nlater, when you cant figure out why your system doesn’t reboot when you finish\nthe install.\n<\/p>\n<p>\nAs you are actually doing the installation,\nthe process of documenting your system continues. Depending on what type of\ninstallation you choose, you may or may not have the opportunity to see many of\nthe programs in action. If you choose an automatic installation, many of the\nprograms run without your interaction, so you never have a chance to see and\ntherefore document the information.\n<\/p>\n<p>\nThe information you need to document are\nthe same kinds of things I talked about in the section on finding out how your\nsystem was configured. It includes the hard disk geometry and partitions\n(<command>fdisk<\/command>), file systems (<command>mount<\/command> and\n<file type=\"\">\/etc\/fstab<\/file>), the hardware settings\n(<file type=\"\">\/var\/log\/messages<\/file>), and every patch you have ever\ninstalled. You can send the\noutput to all of these commands to a file that you can print out and stick in\nthe notebook.\n<\/p>\n<p>\nI don’t know how many times I have said it and how many articles (both mine and\nothers) in which it has appeared, some people just don’t want to listen. They\noften treat their computer systems like a new toy at Christmas. They first want\nto get everything installed that is visible to the outside world, such as\nterminals and printers. In this age of “Net-in-a-box,” often that extends to\ngetting their system on the Internet as soon as possible.\n<\/p>\n<p>\nAlthough being able to download the synopsis of your favorite <a href=\"http:\/\/memory-alpha.org\/en\/wiki\/Star_Trek:_Deep_Space_Nine\">Deep Space Nine<\/a>\nepisode is an honorable goal for some, Chief O’Brien is not going to come to\nyour rescue when your system crashes. (I think even he would have trouble with\nthe antiquated computer systems of today.)\n<\/p>\n<p>\nOnce you have finished installing the <glossary>operating system<\/glossary>,\n the very first device you need\nto install and configure correctly is your tape drive. If you don’t have a tape\ndrive, buy one! Stop reading right now and go out and buy one. It has been\nestimated that a “down” computer system costs a company, on the average, $5,000\nan hour. You can certainly convince your boss that a tape drive that costs\none-tenth as much is a good investment.\n<\/p>\n<p>\nIf you have less data than fits on a DVD (less than 4GB\/8GB), you could buy yourself a DVD writer.\n<\/p>\n<p>\nOne of the first <glossary>crash<\/glossary>\ncalls I\nreceived while I was in tech support was from the system <glossary>administrator<\/glossary>\nat a major airline. After\nabout 20 minutes, it became clear that the situation was hopeless. I had\ndiscussed the issue with one of the more senior engineers who determined that\nthe best course of action was to reinstall the OS and restore the data from\nbackups.\n<\/p>\n<p>\nI can still remember their system <glossary>administrator<\/glossary>\nsaying, “What backups? There are no backups.”<\/p>\n<p>“Why not?” I asked.<\/p>\n<p>“We don’t have a tape drive.”<\/p>\n<p>“Why not?”<\/p>\n<p>“My boss said it was too expensive.”<\/p>\n<p>At that point the only solution was data recovery service.<\/p>\n<p>“You don’t understand,” he said. “There is more than $1,000,000 worth of\nflight information on that machine.”<\/p>\n<p>“Not any more.”<\/p>\n<p>\nWhat is that lost data worth to you? Even\nbefore I started writing my first book, I bought a tape drive for my home\nmachine. For me, it’s not really a question of data but rather, time. I don’t\nhave that much data on my system. Most of it can fit on a half-dozen floppies.\nThis includes all the configuration files that I have changed since my system\nwas installed. However, if my system was to <glossary>crash<\/glossary>, the\ntime I save restoring everything from tape compared to <em>reinstalling\n<\/em>from floppies is worth the money I spent.\n<\/p>\n<p>\nAs technology progressed, CD\/DVD writers became cheaper than tape drives. Current\nI make backups onto DVD of the most important data, so I can get to it\nquickly, but I use my tape drive to backup <i>all<\/i> of the data and system\nfiles, as it won’t fit on a DVD.\n<\/p>\n<p>\nThe first\nthing to do once the tape drive is installed is to test it. The fact that it\nappears at <glossary>boot<\/glossary> says\nnothing about its functionality. It has happened enough that it appears to work\nfine, all the commands behave correctly, and it even looks as though it is\nwriting to the tape. However, it is not until the system goes down and the data\nis needed that you realize you cannot read the tape.\n<\/p>\n<p>\nI suggest first trying the tape drive by backing up a small\n<glossary>subdirectory<\/glossary>, such as <directory>\/etc<\/directory>. There\nare enough files to give the tape drive a quick workout, but you don’t have to\nwait for hours for it to finish. Once you have verified that the basic utilities\nwork (like <command>tar<\/command> or <command>cpio<\/command>), then try backing up the entire system. If you don’t\nhave some third-party back-up software, I recommended that you use cpio.\nAlthough tar can back up most of your system, it cannot backup\n<glossary>device nodes<\/glossary>.\n<\/p>\n<p>\nIf the\nLinux commands are too cumbersome (and they are for many newcomers), a couple of\ncommercial products are available. One such product is Lone-Tar from Cactus\nInternational. I have used Lone-Tar for years on a few systems and have found it\nvery easy to use. The front end is mostly shell scripts that you can modify to\nfit your needs.\n<\/p>\n<p>\nIn general, Lone-Tar takes a differential approach to\nmaking backups. You create one Master Backup and all subsequent backups contain\nthose files that have changed since the master was created. I find this the best\napproach if your master backup takes more than one tape. However, if it all fits\non one tape, you can configure Lone-Tar always to do masters.\n<\/p>\n<p>\nCactus also produces several other products for Linux, including Kermit, and\nsome excellent <glossary>DOS<\/glossary>\ntools. I suggest you check them out. Demo versions are available from the\n<a href=\"http:\/\/www.cactus.com\">cactus Web site<\/a>.\n<\/p>\n<p>\nLike religion, it’s a matter of personal preference. I use Lone-Tar for\nLinux along with their <glossary>DOS<\/glossary>\nTar product because I have a good relationship with the company\npresident, Jeff Hyman. Lone-Tar makes\nbackups easy to make and easy to restore. There is even a Linux demo on the <a\nhref=\"www.lonetar.com\">Lone-Tar Web site<\/a>. The Craftworks distribution has a\ndemo version of the BRU backup software.\n<\/p>\n<p>\nAfter you are sure that\nthe tape drive works correctly, you should create a boot\/root floppy. A\nboot\/root floppy is a pair of floppies that you use to\n<glossary>boot<\/glossary> your system. The first floppy contains the necessary\nfiles to boot and the root floppy contains the root file system.\n<\/p>\n<p>\nNow that you are sure that your tape drive\nand your boot\/root floppy set work, you can begin to install the rest of your\nsoftware and hardware. My preference is to completely install the rest of the\nsoftware first, before moving on to the hardware. There is less to go wrong with\nthe software (at least, little that keeps the system from booting) and you can,\ntherefore, install several products in succession. When installing hardware, you\nshould install and test each component before you go on to the next one.\n<\/p>\n<p>\nI think it is a\ngood idea to make a copy of your <glossary>kernel<\/glossary>\nsource (<directory>\/usr\/src\/linux<\/directory>) before you make any changes to your\nhardware configuration or add any patches. That way, you can quickly restore the\nentire directory and don’t have to worry about restoring from tape or the\ndistribution <glossary>CD-ROM<\/glossary>.\n<\/p>\n<p>\nI suggest that\nyou use a name that is clearer than <directory>\/usr\/src.BAK<\/directory>. Six months after you create\nit, you’ll have no idea how old it is or whether the contents are still valid.\nIf you name it something like <directory>\/usr\/src.06AUG95<\/directory>, it is obvious when it was\ncreated.\n<\/p>\n<p>\nNow, make the changes and test the new\nkernel. After you are sure that the new <glossary>kernel<\/glossary>\nworks correctly, make a new copy of the kernel source\nand make more changes. Although this is a slow process, it does limit the\npotential for problems, plus if you do run into problems, you can easily back\nout of it by restoring the backup of the link kit.\n<\/p>\n<p>\nAs you make the changes, remember to record all the hardware and software\nsettings for anything you install. Although you can quickly restore the\nprevious copy of the <glossary>kernel<\/glossary> source if\nsomething goes wrong, writing down the changes can be helpful if you need to\ncall tech support or post a message to the Internet.\n<\/p>\n<p>\nOnce the system is configured the way you want, make a backup\nof the entire installed system on a different tape than just the base\n<glossary>operating system<\/glossary>. I like to\nhave the base <glossary>operating system<\/glossary>\non a separate tape in case I want to make some major revisions to my\nsoftware and hardware configuration. That way, if something major goes wrong, I\ndon’t have to pull out pieces, hoping that I didn’t forget something. I have a\nknown starting point from which I can build.\n<\/p>\n<p>\nAt this point, you should come up with a back-up schedule. One of the first\nthings to consider is that you should backup as often as necessary. If you can\nonly afford to lose one days worth of work, then backing up every night is fine.\nSome people back up once during lunch and once at the end of the day. More often\nthan twice a day may be too great a load on the system. If you feel that you\nhave to do it more often, you might want to consider\n<glossary>disk mirroring<\/glossary>\nor some other level of <glossary>RAID<\/glossary>.\n<\/p>\n<p>\nThe latest <glossary>kernel<\/glossary>\nversions support <glossary>RAID<\/glossary> 0 (disk striping), which, although it\nprovides an improvement in performance, has no redundancy. Currently (Sep 2006), I am not\naware of any software RAID solutions, though some hardware solutions might work\nwith Linux.\n<\/p>\n<question id=\"\" type=\"mc\" text=\"What kind of backup would you do to backup all files regardless of when they changed?\" \/>\n<p>\nThe type of backup you\ndo depends on several factors. If it takes 10 tapes to do a backup, then doing a\nfull backup of the system (that is, backing up <em>everything<\/em>) every night\nis difficult to swallow. You might consider getting a larger tape drive. In a\ncase where a full backup every night is not possible, you have a few\nalternatives.\n<\/p>\n<p>\nFirst, you can make a list of the directories that\nchange, such as <directory>\/home <\/directory>and\n<directory>\/etc<\/directory>. You can then use tar just to\nbackup those directories. This has the disadvantage that you must manually find\nthe directories that change, and you might miss something or back up too\nmuch.\n<\/p>\n<question id=\"\" type=\"MC\" text=\"What is the difference between a full backup and incremental backup.\" \/>\n<p>\nNext, there are incremental\nbackups. These start with a master, which is a backup of the entire system. The\nnext backup only records the things that have changed since the last\nincremental. This can be expanded to several levels. Each level backs up\neverything that has changed since the last backup of that or the next lower\nlevel.\n<\/p>\n<concept id=\"\" description=\"A master backup does not necessarily copy every single file on your system.\" \/>\n<concept id=\"\" description=\"Master backups can be created for a sub-set of the files on your system.\"\n \/>\n<question id=\"\" type=\"TF\" text=\"Master backups can be created for a sub-set of the files on your system.\" \/>\n<p>\nNote that often the term “master” is used with a specific set of data. For example, you might have master database backup or a master webserver backup, neither of which are a complete system backup. As long as you are consistent in your terminology, this does not really matter. For example, you can create an incremental webserver backup to go along with the master webserver backup, just as you can create an incremental system backup to go along with the master system backup.\n<\/p>\n<question id=\"\" type=\"MC\" text=\"Given three levels of backups, what would the differences be between a level 0, 1 and 2 backups.\" \/>\n<p>\nFor example, level 2 backs up everything since the last level 1 or the last level\n0 (whichever is more recent). You might do a level 0 backup once a month (which\nis a <em>full<\/em> backup of everything), then a level 1 backup every Wednesday\nand Friday and a level 2 backup every other day of the week. Therefore, on\nMonday, the level 2 will back up everything that has changed since the level 1\nbackup on Friday. The level 2 backup on Tuesday will back up everything since\nthe level 2 backup on Monday. Then on Wednesday, the level 1 backup backs up\neverything since the level 1 backup on the previous Friday.\n<\/p>\n<p>\nAt the end of the month, you do a level 0 backup that backs\nup everything. Lets assume this is on a Tuesday. This would normally be a level\n2. The level 1 backup on Wednesday backs up everything that has changed since the level 0 backup\n(the day before) and not since the level 1 backup on the previous Friday.\n<\/p>\n<question id=\"\" type=\"mc\" text=\"What is a 'differential' backup?\" \/>\n<question id=\"\" type=\"mc\" text=\"What kind of backup would you make to backup all file which have changed since the last full backup?\" \/>\n<concept id=\"\" description=\"A 'differential' backup simply stores the 'difference' between the last master backup and the current state.\" \/>\n<p>\nA somewhat simpler scheme uses differential backups.\nHere, there is also a master. However, subsequent backups will record\n<em>everything<\/em> that has changed (is different) from the master. If you do\na master once a week and differentials once a day, then something that is\nchanged on the day after the master is recorded on every subsequent backup.\n<\/p>\n<p>\nA modified version of the differential backup does a complete, level 0 backup\non Friday. Then on each of the other days, a level 1 backup is done. Therefore,\nthe backup Monday-Thursday will backup everything since the day before. This is\neasier to maintain, but you may have to go through five tapes.\n<\/p>\n<p>\nThe third type, the simplest method, is where you do a master backup every day\nand forget about increments and differences. This is the method I prefer if the\nwhole system fits on one tape because you save time when you have to restore\nyour system. With either of the other methods, you will probably need to go\nthrough at least two tapes to recover your data, unless the crash occurs on the\nday after the last master. If you do a full backup every night, then there is\nonly one backup to load. If the backup fits on a single tape (or at most, two),\nthen I highly recommend doing a full backup every night. Remember that the key\nissue is getting your people back to work as soon as possible. The average\n$5,000 per hour you stand to loose is much more than the cost of a larger\ntape drive. (ca. 80Gb, Sep. 2006)\n<\/p>\n<p>\nThis brings up another issue, and that is rotating tapes. If\nyou are making either incremental or differential backups, then you\n<em>must<\/em> have multiple tapes. It is illogical to make a master then make an\nincremental on the same tape. There is no way to get the information from the\nmaster. <\/p>\n<p>\nIf you make a master backup on the same tape very\nnight, you can run into serious problems as well. What if the system crashes in\nthe middle of the backup and trashes the tape? Your system is gone and so is\nthe data. Also, if you discover after a couple of days that the information in a\nparticular file is garbage and the master is only one day old, then it is\nworthless for getting the data back. Therefore, if you do full backups every\nnight, use at least five tapes, one for each day of the week. (If you run seven\ndays a week, then seven tapes is likewise a good idea.)\n<\/p>\n<p>\nYou don’t necessarily always have to back up to tape. If the\namount of data that changes is fairly small, you could backup to floppies. This\nis probably only valid if your system is acting as a Web server and the data\nchange at irregular intervals. As with any backup, you need to weigh the time to\nrecreate the data against the time to make the backup. If your data on the Web\nserver is also stored elsewhere (like on the development machine), it may be\neasier to back up the Web server once after you get your configuration right,\nand then skip the backups. However, it’s your call.\n<\/p>\n<p>\nOther choices for backup media include WORM (Write Once\/Read\nMany) drive and CD-Recordable. This is only effective if the data isn’t going to\nchange much. You could back up your Web server to one of these media and then\nquickly recovered it if your machine crashes. Copy the data to another machine\non the <glossary>network<\/glossary> where a backup is done. (You could also\nmount the file system you want to back up via <glossary>NFS<\/glossary>.\n)<\/p>\n<p>\nAlthough most people get this far in\nthinking about the backup media, many forget about the physical safety of the media. If\nyour computer room catches fire and the tapes or DVDs melt, then the most efficient\nbackup scheme is worthless. Some companies have fireproof safes in which they\nkeep the tapes. In smaller operations, the system administrator can take the\ntape home from the night before. This is normally only effective when you do\nmasters every night. If you have a lot of tapes, you might consider companies\nthat provide off-site storage facilities.\n<\/p>\n<p>\nI worked for one datacenter provider which had a customer who paid for a courier to pick up “clones” of the master backup tapes once a week. There was a full system backup on the weekend to tape and these tapes where then copied (cloned). On Tuesday, the courier would return the tapes from the previous week and pickup the new ones.\n<\/p>\n<p>\nAlthough some commercial products are available (which I will get\ninto in a moment), you can use the tools on your system. For example, you can\nuse <command>tar<\/command> or <command>cpio<\/command>. Although\ntar is a bit easier to use, cpio\ndoes have a little more functionality. The tar\ncommand has the following basic format:<\/p>\n<p>\n<commandexample command=\"tar\">tar options files<\/commandexample>\n<\/p>\n<p>\nAn example might be\n<\/p>\n<question id=\"\" type=\"mc\" text=\"What command would backup the \/data1 directory?\" \/>\n<p>\n<commandexample command=\"tar\">tar cvf \/dev\/fd0 \/home \/etc<\/commandexample>\n<\/p>\n<p>\nThis example would back\nup <directory>\/home<\/directory> and <directory>\/etc<\/directory>\nand write them to the floppy tape device <device>\/dev\/fd0<\/device>. The\nc option says to create an archive,\nv is verbose mode in which all the files are output to\nstdout, and f says that\ntar should output to the following <i>file<\/i>. In this\ncase, you are outputting to the device file <device>\/dev\/fd0<\/device>.\n<\/p>\n<p>\nIf you have a lot of directories, you can use the T\noption to specify file containing the directories to backup. For example, if you\nhad file called file_list that contained the list of directories, the\ncommand might look like this:\n<\/p>\n<p>\n<commandexample command=\"tar\">tar cvfT \/dev\/rft0 file_list<\/commandexample>\n<\/p>\n<p>\nTo extract files, the syntax is essentially the same, except\nthat you use the x option to extract. However, you can still\nuse both the f and T\noptions.\n<\/p>\n<p>\nThe GNU version of <command>tar<\/command> (which comes\nwith most versions of Linux) has a very large number of options. One option I use is\nz, which I use to either compress or uncompress the archive (depending on\nwhich direction I am going). Because the archive is being filtered through\ngzip, you need to have <command>gzip<\/command> on\nyour system. Although gzip is part of every Linux\ndistribution, it may not be on your system. Also, if you want to copy the\narchive to another UNIX system, that system may not have gzip. Therefore, you\ncan either skip the compression or use the Z (notice the\nuppercase) to use <command>compress<\/command> and <command>uncompress<\/command>.\n<\/p>\n<p>\nAlthough I can imagine situations in which they might\nbe useful, I have only used a few of them. The best place to look is the\ntar <glossary>man-page<\/glossary>.\n<\/p>\n<question id=\"\" type=\"mc\" text=\"In regards to backup tapes, what is a 'file mark'?\" \/>\n<p>\nIf your backup media can handle more than one set of\nbackups, you can use the <command>mt<\/command> command to manage your tape\ndrive. Among the functions that <command>mt<\/command> can do is to write a\n“file mark,” which is simply a marker on the tape to indicate the end of an\narchive. To use this function, you must first back the backup to the no-rewind\ntape device (for example, <device>\/dev\/rft0<\/device>). When the drive has written all of the archive to the tape, write the file marker to indicate where the end is.\n<\/p>\n<p>\nNormally, when\ntar is complete and the tape device is closed, it rewinds. When you use\nthe no-rewind device, the tar process finishes, but the tape\ndoes not rewind. You can then use the <command>mt<\/command> command to write\nthe file mark at the tapes current location, which is at the end of the\ntar archive. Even if there are multiple archives on the single tape,\nmt will find the specific location. Therefore, whenever you\nneed to restore, you can access any of the archives. See the mt\n<glossary>man-page<\/glossary>\nfor more detail.\n<\/p>\n","protected":false},"excerpt":{"rendered":"<p>Preparing Yourself Problem-solving starts before you have even installed your system. Because a detailed knowledge of your system is important to figuring out what’s causing problems, you need to keep track of your system from the very beginning. One most … <a href=\"http:\/\/www.linux-tutorial.info\/?page_id=335\">Continue reading <span class=\"meta-nav\">→<\/span><\/a><\/p>\n","protected":false},"author":1,"featured_media":0,"parent":0,"menu_order":0,"comment_status":"closed","ping_status":"closed","template":"","meta":{"footnotes":""},"class_list":["post-335","page","type-page","status-publish","hentry"],"_links":{"self":[{"href":"http:\/\/www.linux-tutorial.info\/index.php?rest_route=\/wp\/v2\/pages\/335","targetHints":{"allow":["GET"]}}],"collection":[{"href":"http:\/\/www.linux-tutorial.info\/index.php?rest_route=\/wp\/v2\/pages"}],"about":[{"href":"http:\/\/www.linux-tutorial.info\/index.php?rest_route=\/wp\/v2\/types\/page"}],"author":[{"embeddable":true,"href":"http:\/\/www.linux-tutorial.info\/index.php?rest_route=\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"http:\/\/www.linux-tutorial.info\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=335"}],"version-history":[{"count":1,"href":"http:\/\/www.linux-tutorial.info\/index.php?rest_route=\/wp\/v2\/pages\/335\/revisions"}],"predecessor-version":[{"id":663,"href":"http:\/\/www.linux-tutorial.info\/index.php?rest_route=\/wp\/v2\/pages\/335\/revisions\/663"}],"wp:attachment":[{"href":"http:\/\/www.linux-tutorial.info\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=335"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}