Experienced little things-4, or "Let's face it backups?"

    imageContinuation of "experimental trifles." Previous parts: one , two , three .

    Today I will talk about the principles of backup , which were built as a result of trial and error, and more than once saved the situation at the most seemingly unexpected moment.

    Backups are an accident insurance company. Making backups is not even a rule, it is an axiom. Whatever the burnt admin, sometimes his “hand tremble” may sometimes happen, and a script that is written incorrectly, or a randomly pressed button can do a lot of trouble, let alone HDD, fire and other disasters. Yes, backups are expensive (time, resources, equipment), their momentary effect is not obvious, but the main thing that they give is insurance of company risks. And this is worth a lot. It would seem that the statements are understandable to everyone, but often there is a situation when the server crashes, there is a backup, but nothing can be done, the system is not restored. And the dances for a tambourine with an orchestra begin, pulling out at least some data, etc. joys.

    First, let's introduce and clearly separate concepts such as archiving and backup. For example, like this:
    • Archiving is a backup with LONG-TERM data storage. The procedure, when once copied, and carried to a bank safe. Contacting the archive is more an exception than the rule, and the procedure can be quite lengthy (depending on where and how the archives are stored).
    • Backup is a backup with SHORT-TERM data storage. The procedure, when copying occurs regularly, the media are overwritten, there is the concept of “storage depth”. At the same time, access to the backup should usually be as fast as possible.

    Archiving



    Archiving is not necessary for everyone and not always. Most often this question arises when a company goes beyond “I, my friend, wife and courier”, and usually concerns only files, financial databases, mail databases, i.e. those documents that are accepted and non-electronic life to keep in archives (letters, orders, accounting primary, etc.).
    Archives are usually made once a year and stored on external media somewhere in a safe, in a bank cell, in the cottage of the general director (underline what is necessary). Everything is clear here on the whole, the main thing is not to forget to check the archive status at least once a year (for example, while recording a new one, restore part of the data from the old one) and monitor the media so that you can always read the archive of any depth (for example, I had a situation when you needed an archive that was made 5 years ago and was stored on a tape, a streamer for which was not only broken and written off, but wasn’t released for a long time. )

    The last couple of years, by the way, more often for archives we use not tapes, but banal HDDs. Their volumes are enough, the speed of work is sufficient for the archive, the price is reasonable, and a single connection interface (formerly IDE, now SATA) eliminates the problem of a “broken streamer”, which is important, because data can be read on virtually any computer, without the involvement of special equipment (as is the case with tapes). When the IDE completely disappears, we will probably copy it to SATA (or whatever happens afterwards).

    Backup


    The task of the backup as such is to keep fresh backup copies, for quick recovery of “accidentally \ specially deleted”, or “burned out”, or “incorrectly configured”. If archives are usually stored as long as the organization lives, and sometimes longer, then for backups you can already introduce the concept of storage depth , i.e. the time after which the backup will be outdated, and it can be overwritten with more recent data. Backup in general can be divided into two main parts: data backup and backup systems , and a stand-alone backup of the contents of systems. The latter is a very extensive and specific topic, highly dependent on the content of which particular systems you want to backup (mail server, database, CRM, software settings, etc.), we will not describe it here.

    Backup systems

    A backup of systems is when you need to backup not individual files, but the entire system, which can consist of several components (for example, special software, SQL database, file data), and it is better to restore it in its entirety than in parts. Everything is quite simple here: choose a backup software that suits you (price, functionality, convenience) and backup the system so that you can guaranteed to restore it, even in the event of a complete server failure. All kinds of Acronis, Symantec System Recovery, etc. are suitable. It is important to remember this:
    • You must be ABLE to restore from backup. Train anywhere, anytime, but YOU SHOULD BE ABLE to do this.
    • think over what exactly you backup. This is significant for universal servers, when, for example, a database is spinning on one server, your intracorporate site and the volume is additionally attached to file resources. In such a situation, you shouldn’t back up the second file volume of 1,500 TB with it at the same time for the sake of backing up the complex-configured SQL + your site link. In general, strive for a “one task, one server” situation, do not hang everything, everything, everything on one machine, and if you hang it, then backup it “systemically”.
    • your software should be able to recover to other hardware that is different from the current one. And you should try it at least once!
    • “Systemic” backups, especially systems that are constantly used, should not be stored for more than a week. Think for yourself, why do you need a backup of your domain controller a month ago? In case of emergency, you will need the MOST fresh backup. And all the rest is a safety net, in case the “freshest” one for some reason did not work. Allocating more than 1-2 iterations to such a safety net, in my opinion, is illogical and unnecessarily consumes space.
    • there are systems that are complexly interconnected with the entire infrastructure, and restoring them, even having a fresh “system backup” of a specific server at hand, is not easy. Offhand: Active Directory, Exchange, etc. Take time, study the documentation, and in a test environment, at least once - but try to restore ABSOLUTELY EVERYTHING! It’s better to learn how to do it in a relaxed atmosphere with the Internet at hand than with an angry boss over your head.

    Data backup

    A data backup is a backup of separate, independent data (basically this is the contents of your corporate file storage). There is no need for much wisdom here - take it and copy it, you can only think about the backup scheme. For example, I adhere to the following scheme:

    1. On weekends, a full backup of all data is made. The storage depth is 28 days, i.e. There are four independent full backups. Thus, over the last month we will be able to recover data for any day off.
    2. On working days, a differential backup is made, with a storage depth of 14 days. Thus, over the past two weeks, we can restore data for any of the days.
    3. on the first weekend of each month, separately from the rest of the work, a monthly backup is made, with a storage depth of 12 months. This is a cross between backup and archive. On the one hand, the shelf life is quite large, on the other - a situation is often when you need to restore data “a couple of months ago, a maximum of six months”. Alternatively, you can not do a monthly backup as a separate work, but simply copy a suitable weekly backup.

    In addition, I try to adhere to these rules:
    • I use differential, but not incremental backup. (If you do not know what it is - be sure to read the documentation, these are very important concepts). The gain in recovery speed is more important to me than in the volume of backups.
    • I plan backup time so that I can keep up until the morning. If the backup takes longer - I break it down into several jobs, several servers, or raise a question about other, more high-speed equipment.
    • in the backup schedule I try to adhere to the intervals associated with the weeks (7 days, 28 days, etc.) and not get attached to the "first / last days of the month". A week is a fairly constant value, 7 days and in most cases Saturday, Sunday are days off.
    • I use disks, not tapes. I do not like the expensive streamer intermediary between the data in the backup and the data in the file storage. If for some reason it does not work, then the entire backup system will be violated for a long time. If you use hard drives, then this can be avoided.
    • I try to ensure that a logically independent part of the data is in a separate backup. For example, if we talk about Symantec Backup Exec, then one job = one media. I really don’t like the situation when one work is “spread out” across several files. This not only introduces confusion into the system, but also in the event of accidentally overwriting one of the files (“hand trembled”), it harms not only one work but also all the neighboring ones.
    • without fail I use software with notifications by mail. If this is a self-written script - no one bothers to add a piece that will check at least the presence of a new backup, its size and send data by mail. This greatly saves time in monitoring backup.

    Among other things, it is also fashionable to use the so-called. “Instant” backups, of small depth (1-2 days) a la VSS service in Windows, when users themselves can choose what to restore from the latest versions of the document. This helps a lot when the user edited the document in the morning, and deleted it in the afternoon and asks to restore the morning version.
    You can also use the DFS system as a permanent online backup, but this is described in a separate post, which I will do later.

    To be continued.

    PS Let me remind you, I do not set the rules, but share my experience, non-universal experience gained in small organizations (30-500 PCs). If it’s customary for you to do otherwise, I will read about it with pleasure in the comments.

    Also popular now: