{"id":30649,"date":"2019-10-31T21:36:42","date_gmt":"2019-10-31T18:36:42","guid":{"rendered":"https:\/\/prohoster.info\/blog\/bekap-nagotove-razrushaem-mify-v-chest-prazdnika\/"},"modified":"2019-10-31T21:36:42","modified_gmt":"2019-10-31T18:36:42","slug":"bekap-nagotove-razrushaem-mify-v-chest-prazdnika","status":"publish","type":"post","link":"https:\/\/prohoster.info\/da\/blog\/administrirovanie\/bekap-nagotove-razrushaem-mify-v-chest-prazdnika","title":{"rendered":"Backup klar: Afd\u00e6kker myter i anledning af festen","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"Backup
\n
\nBackup er ikke en modef\u00e6nomen, der r\u00e5bes om fra hver facade. Det b\u00f8r blot v\u00e6re en given del af enhver seri\u00f8s virksomhed, that's it. I vores bank sikkerhedskopieres flere tusinde servere \u2013 det er et komplekst og interessant arbejde, og der er nogle nuancer, s\u00e5vel som almindelige misforst\u00e5elser om backups, som jeg gerne vil fort\u00e6lle om.
\n<\/a><\/noindex>
\nJeg har arbejdet med dette emne i n\u00e6sten 20 \u00e5r, hvoraf de sidste 2 \u00e5r har v\u00e6ret i Promsvyazbank. I begyndelsen af min praksis lavede jeg backup n\u00e6sten manuelt, med scripts, der blot kopierede filer. Senere dukkede der praktiske v\u00e6rkt\u00f8jer op i Windows: v\u00e6rkt\u00f8jet Robocopy til forberedelse af filer og NT Backup til kopiering. Og s\u00e5 kom tiden til specialiseret software, f\u00f8rst og fremmest Veritas Backup Exec, som nu kaldes Symantec Backup Exec. S\u00e5 jeg har v\u00e6ret bekendt med backups i lang tid.<\/p>\n

Hvis vi taler simpelt, er backup processen til at bevare en kopi af data (virtual machines<\/a>, applikationer, databaser og filer) for en sikkerheds skyld med en bestemt regelm\u00e6ssighed. En sikkerheds skyld manifesterer sig typisk som et hardware- eller logisk fejlslag, hvilket f\u00f8rer til datatab. Form\u00e5let med backupsystemet er at minimere tabet ved datatab. Hardwarefejl er for eksempel en serversvigt eller et opbevaringssystem, hvor databasen ligger. Logisk fejl er tab eller \u00e6ndring af dele af data, herunder p\u00e5 grund af menneskelige faktorer: en tabel, en fil er utilsigtet slettet, eller en fejlbeh\u00e6ftet script er k\u00f8rt. Der er ogs\u00e5 regulatoriske krav om opbevaring af visse typer information i en l\u00e6ngere periode, for eksempel i op til flere \u00e5r.<\/p>\n

\"Backup
\n
\nDen mest typiske anvendelse af backups er at gendanne den gemte kopi af databasen for at implementere forskellige testsystemer, kloner til udviklere.<\/p>\n

Der er flere typiske myter omkring backup, som det er p\u00e5 h\u00f8je tid at aflive. Her er de mest kendte af dem. <\/p>\n

Myte 1. Backup er i dag kun en lille funktion inden for sikkerheds- eller opbevaringssystemer.<\/h3>\n

\nBackup systems still remain a distinct class of solutions, and a rather independent one. They are entrusted with an exceptionally important task. Essentially, they serve as the last line of defense when it comes to data preservation. Thus, backups operate on their own rhythm, according to their own schedule. Daily reports are generated for the servers, and certain events act as triggers for the monitoring system.<\/p>\n

\"Backup
\n
\nAdditionally, the role-based access model for the backup system allows delegating some powers to administrators of target systems for managing backups.<\/p>\n

Myth 2. With RAID, backups are no longer needed.<\/h3>\n

\n\"Backup
\n
\nUndoubtedly, RAID arrays and data replication are a good way to protect information systems from hardware failures, and with a standby server, it's possible to quickly switch to it if the primary machine fails.<\/p>\n

However, redundancy and replication do not protect against logical errors made by users of the system. A standby server with delayed recording can indeed help if the mistake is detected before synchronization occurs. But what if the moment is missed? Only a timely backup can help here. If it is known that the data changed yesterday, the system can be restored to its state from the day before yesterday to retrieve the necessary data. Considering that logical errors are the most frequent, the old reliable backup remains a proven and necessary tool.<\/p>\n

Myth 3. A backup is something that is done once a month.<\/h3>\n

\nThe frequency of backups is a configurable parameter primarily dependent on the requirements of the backup system. It is quite possible to find data that hardly ever changes and is not critically important, and losing it would not be devastating for the company.
\nThey can actually be backed up once a month or even less frequently. However, more critical data is saved more often, depending on the RPO (Recovery Point Objective) metric, which defines the acceptable data loss. This could be once a week, once a day, or even several times an hour. For us, this refers to transaction logs from the database management system.<\/p>\n

\"Backup
\n
\nN\u00e5r systemer tages i brug i industrien, skal der altid godkendes dokumentation for backup, som beskriver de vigtigste punkter, opdateringsregler, procedurer for gendannelse af systemet, opbevaringsprocedurer for backupkopier og lignende.<\/p>\n

Myte 4. M\u00e6ngden af kopier vokser konstant og fylder alt det tildelte rum helt.<\/h3>\n

\nBackupkopier har en begr\u00e6nset opbevaringsperiode. Det giver ikke mening at gemme alle 365 daglige backups over et \u00e5r. Generelt er det tilladt at opbevare daglige kopier i 2 uger, hvorefter de erstattes af nye, mens den version, der blev lavet f\u00f8rst i m\u00e5neden, forbliver til langvarig opbevaring. Denne bliver ogs\u00e5 opbevaret i en begr\u00e6nset periode \u2013 hver kopi har sin egen livstid.<\/p>\n

\"Backup
\n
\nDer er beskyttelse mod datatab. Der g\u00e6lder den regel, at f\u00f8r en backup slettes, skal den n\u00e6ste v\u00e6re genereret. Derfor vil data ikke blive slettet, hvis backupen ikke er udf\u00f8rt, for eksempel p\u00e5 grund af serverens utilg\u00e6ngelighed. B\u00e5de tidsrammer overholdes, og antallet af kopier i s\u00e6ttet kontrolleres. Hvis systemet er indstillet til, at der altid skal v\u00e6re to komplette backups, vil der altid v\u00e6re to, og den gamle vil kun blive slettet, n\u00e5r en ny tredje backup er blevet skrevet succesfuldt. S\u00e5 v\u00e6ksten i m\u00e6ngden af plads, der bruges af backuparkivet, er kun relateret til stigningen i m\u00e6ngden af beskyttede data og er ikke afh\u00e6ngig af tid.<\/p>\n

Myte 5. Backupstart \u2013 alt h\u00e6nger.<\/h3>\n

\nMan kan bedre sige det s\u00e5dan: hvis alt h\u00e6nger, s\u00e5 er administratorens h\u00e6nder ikke p\u00e5 rette sted. Generelt afh\u00e6nger hastigheden af backup af mange faktorer. For eksempel afh\u00e6nger det af hastigheden af selve backup-systemet: hvor hurtige disklagringer og b\u00e5ndbiblioteker der er. Fra hastigheden af servere<\/a> backup-systemet: om de kan behandle data, foretage komprimering og deduplicering. S\u00e5vel som fra hastigheden af kommunikationslinjerne mellem klienten og serveren. <\/p>\n

Backup kan foreg\u00e5 i en eller flere tr\u00e5de, afh\u00e6ngigt af om det reserverede system underst\u00f8tter multithreading. For eksempel g\u00f8r databasesystemet Oracle det muligt at afgive flere tr\u00e5de svarende til antallet af tilg\u00e6ngelige processorer, indtil overf\u00f8rselshastigheden n\u00e5r netv\u00e6rksb\u00e5ndbreddegr\u00e6nsen.<\/p>\n

Hvis man fors\u00f8ger at tage backup med et stort antal tr\u00e5de, er der risiko for at overbelaste det aktive system, hvilket virkelig vil medf\u00f8re nedsat ydeevne. Derfor v\u00e6lges det optimale antal tr\u00e5de for at sikre tilstr\u00e6kkelig hastighed. Hvis selv det mindste fald i ydeevne er kritisk, er der en fremragende l\u00f8sning, hvor backup udf\u00f8res fra en klon af produktionsserveren \u2013 standby i databasedelen. Denne proces belaster ikke det prim\u00e6re arbejdssystem. Data kan hentes gennem et st\u00f8rre antal tr\u00e5de, da serveren ikke bruges til at h\u00e5ndtere belastningen.<\/p>\n

I store organisationer oprettes der et separat netv\u00e6rk til backup-systemet, s\u00e5 backup ikke p\u00e5virker produktionen. Desuden kan trafikken sendes ikke gennem netv\u00e6rket, men via SAN.
\n\"Backup
\nVi pr\u00f8ver ogs\u00e5 at fordele belastningen over tid. Backups udf\u00f8res prim\u00e6rt i arbejdstimerne, om natten eller i weekenden. Derudover startes de ikke alle p\u00e5 \u00e9n gang. Backups af virtuelle maskiner er et s\u00e6rligt tilf\u00e6lde. Processen p\u00e5virker n\u00e6sten ikke maskinens ydeevne, s\u00e5 backup kan str\u00e6kkes over dagtimerne i stedet for at blive udskudt til natten. Der er mange nuancer, men hvis alt tages i betragtning, vil backup ikke p\u00e5virke systemernes ydeevne.<\/p>\n

Myte 6. Jeg startede backup-systemet \u2013 s\u00e5 har jeg redundans.<\/h3>\n

\nGlem aldrig, at backup-systemet er den sidste forsvarslinje, hvilket betyder, at der skal v\u00e6re flere systemer foran det, der sikrer kontinuitet, h\u00f8j tilg\u00e6ngelighed og katastrofem\u00e6ssig modstandsdygtighed i IT-infrastrukturen og virksomhedens informationssystemer.<\/p>\n

Man b\u00f8r ikke h\u00e5be p\u00e5, at backup vil genskabe alle data og hurtigt f\u00e5 den nedbrudte service op at k\u00f8re. Data, der g\u00e5r tabt fra backup-tidspunktet til nedbruddet, er garanteret, og data p\u00e5 den nye server kan tage flere timer (eller dage, alt efter situationen) at overf\u00f8re. Derfor er det fornuftigt at oprette fuldgyldige redundante systemer i stedet for at l\u00e6gge alt over p\u00e5 backup.<\/p>\n

Myte 7. Jeg har kun konfigureret backup \u00e9n gang, kontrolleret at det virker. Nu skal jeg kun tjekke loggene.<\/h3>\n

\nDette er en af de mest skadelige myter, hvis falskhed man f\u00f8rst erkender under en h\u00e6ndelse. Logfiler over succesfuld udf\u00f8relse af backup er ikke en garanti for, at alt virkelig er g\u00e5et som det skal. Det er vigtigt p\u00e5 forh\u00e5nd at kontrollere den gemte kopi for udrulbarhed. Det vil sige at starte genoprettelsesprocessen i et testmilj\u00f8 og se resultatet. <\/p>\n

Og lidt om arbejdet som systemadministrator<\/h3>\n

\nIngen kopierer data manuelt l\u00e6ngere. Moderne backup-l\u00f8sninger kan backup'e n\u00e6sten alt, s\u00e5 l\u00e6nge det er korrekt konfigureret. Hvis der er tilf\u00f8jet en ny server, skal man skrive politikkerne: v\u00e6lge indholdet, der skal sikkerhedskopieres, angive opbevaringsparametre og anvende en tidsplan.<\/p>\n

\"Backup
\n
\nDer er alligevel meget arbejde p\u00e5 grund af det omfattende serverpark, hvor der b\u00e5de findes databaser, mailsystemer, virtuelle maskinkluster og filressourcer b\u00e5de p\u00e5 Windows og Linux\/Unix. Medarbejderne, der opretholder funktionaliteten af backupsystemet, sidder ikke stille.<\/p>\n

I anledning af fejringen vil jeg \u00f8nske alle administratorer st\u00e6rke nerver, pr\u00e6cise bev\u00e6gelser og uendelig plads til opbevaring af backups!<\/p><\/blockquote>\n

Kilde: habr.com<\/a><\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"

\u0420\u0435\u0437\u0435\u0440\u0432\u043d\u043e\u0435 \u043a\u043e\u043f\u0438\u0440\u043e\u0432\u0430\u043d\u0438\u0435 \u043d\u0435 \u043e\u0442\u043d\u043e\u0441\u0438\u0442\u0441\u044f \u043a \u043c\u043e\u0434\u043d\u044b\u043c \u0442\u0435\u0445\u043d\u043e\u043b\u043e\u0433\u0438\u044f\u043c, \u043e \u043a\u043e\u0442\u043e\u0440\u044b\u0445 \u043a\u0440\u0438\u0447\u0430\u0442 \u0438\u0437 \u043a\u0430\u0436\u0434\u043e\u0433\u043e \u0443\u0442\u044e\u0433\u0430. \u041e\u043d\u043e \u043f\u0440\u043e\u0441\u0442\u043e \u0434\u043e\u043b\u0436\u043d\u043e \u0431\u044b\u0442\u044c \u0432 \u043b\u044e\u0431\u043e\u0439 \u0441\u0435\u0440\u044c\u0435\u0437\u043d\u043e\u0439 \u043a\u043e\u043c\u043f\u0430\u043d\u0438\u0438, \u0432\u043e\u0442 \u0438 \u0432\u0441\u0451. \u0423 \u043d\u0430\u0441 \u0432 \u0431\u0430\u043d\u043a\u0435 \u0431\u044d\u043a\u0430\u043f\u0438\u0442\u0441\u044f \u043d\u0435\u0441\u043a\u043e\u043b\u044c\u043a\u043e \u0442\u044b\u0441\u044f\u0447 \u0441\u0435\u0440\u0432\u0435\u0440\u043e\u0432 \u2013 \u044d\u0442\u043e \u0441\u043b\u043e\u0436\u043d\u0430\u044f, \u0438\u043d\u0442\u0435\u0440\u0435\u0441\u043d\u0430\u044f \u0440\u0430\u0431\u043e\u0442\u0430, \u043e \u043d\u0435\u043a\u043e\u0442\u043e\u0440\u044b\u0445 \u0442\u043e\u043d\u043a\u043e\u0441\u0442\u044f\u0445 \u043a\u043e\u0442\u043e\u0440\u043e\u0439, \u0430 \u0442\u0430\u043a\u0436\u0435 \u043e \u0442\u0438\u043f\u0438\u0447\u043d\u044b\u0445 \u0437\u0430\u0431\u043b\u0443\u0436\u0434\u0435\u043d\u0438\u044f\u0445 \u043e\u0442\u043d\u043e\u0441\u0438\u0442\u0435\u043b\u044c\u043d\u043e \u0431\u044d\u043a\u0430\u043f\u043e\u0432 \u043a\u0430\u043a \u0440\u0430\u0437 \u0438 \u0445\u043e\u0447\u0435\u0442\u0441\u044f \u0440\u0430\u0441\u0441\u043a\u0430\u0437\u0430\u0442\u044c. \u042d\u0442\u043e\u0439 \u0442\u0435\u043c\u0430\u0442\u0438\u043a\u043e\u0439 […]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":22639,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[688],"tags":[],"class_list":["post-30649","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-administrirovanie"],"aioseo_notices":[],"aioseo_head":"\n\t\t\n\t\n\t\n\t\n\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\n","aioseo_head_json":{"title":"\ud83e\udd47Backup klar: nedbryder myter i anledning af fejringen | ProHoster","description":"Backup relaterer sig ikke til.","canonical_url":"https:\/\/prohoster.info\/da\/blog\/administrirovanie\/bekap-nagotove-razrushaem-mify-v-chest-prazdnika","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"da_DK","og:site_name":"ProHoster | \u041a\u0443\u043f\u0438\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u0445\u043e\u0441\u0442\u0438\u043d\u0433 \u0434\u043b\u044f \u0441\u0430\u0439\u0442\u043e\u0432 \u0441 \u0437\u0430\u0449\u0438\u0442\u043e\u0439 \u043e\u0442 DDoS, VPS VDS \u0441\u0435\u0440\u0432\u0435\u0440\u044b","og:type":"article","og:title":"\ud83e\udd47\u0411\u044d\u043a\u0430\u043f \u043d\u0430\u0433\u043e\u0442\u043e\u0432\u0435: \u0440\u0430\u0437\u0440\u0443\u0448\u0430\u0435\u043c \u043c\u0438\u0444\u044b \u0432 \u0447\u0435\u0441\u0442\u044c \u043f\u0440\u0430\u0437\u0434\u043d\u0438\u043a\u0430 | ProHoster","og:description":"\u0420\u0435\u0437\u0435\u0440\u0432\u043d\u043e\u0435 \u043a\u043e\u043f\u0438\u0440\u043e\u0432\u0430\u043d\u0438\u0435 \u043d\u0435 \u043e\u0442\u043d\u043e\u0441\u0438\u0442\u0441\u044f \u043a.","og:url":"https:\/\/prohoster.info\/da\/blog\/administrirovanie\/bekap-nagotove-razrushaem-mify-v-chest-prazdnika","og:image":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:secure_url":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:width":350,"og:image:height":350,"article:published_time":"2019-10-31T18:36:42+00:00","article:modified_time":"2019-10-31T18:36:42+00:00","article:publisher":"https:\/\/www.facebook.com\/prohoster","article:author":"https:\/\/www.facebook.com\/prohoster"},"aioseo_meta_data":{"post_id":"30649","title":null,"description":null,"keywords":null,"keyphrases":null,"primary_term":null,"canonical_url":null,"og_title":null,"og_description":null,"og_object_type":"default","og_image_type":"default","og_image_url":null,"og_image_width":null,"og_image_height":null,"og_image_custom_url":null,"og_image_custom_fields":null,"og_video":null,"og_custom_url":null,"og_article_section":null,"og_article_tags":null,"twitter_use_og":false,"twitter_card":"default","twitter_image_type":"default","twitter_image_url":null,"twitter_image_custom_url":null,"twitter_image_custom_fields":null,"twitter_title":null,"twitter_description":null,"schema":{"blockGraphs":[],"customGraphs":[],"default":{"data":{"Article":[],"Course":[],"Dataset":[],"FAQPage":[],"Movie":[],"Person":[],"Product":[],"ProductReview":[],"Car":[],"Recipe":[],"Service":[],"SoftwareApplication":[],"WebPage":[]},"graphName":"","isEnabled":true},"graphs":[]},"schema_type":null,"schema_type_options":null,"pillar_content":false,"robots_default":true,"robots_noindex":false,"robots_noarchive":false,"robots_nosnippet":false,"robots_nofollow":false,"robots_noimageindex":false,"robots_noodp":false,"robots_notranslate":false,"robots_max_snippet":null,"robots_max_videopreview":null,"robots_max_imagepreview":"large","priority":null,"frequency":null,"local_seo":null,"seo_analyzer_scan_date":"2026-02-09 17:13:31","breadcrumb_settings":null,"limit_modified_date":false,"reviewed_by":null,"ai":null,"created":"2021-03-01 03:31:24","updated":"2026-02-09 17:13:31","focus_keyword":null,"additional_keywords":null,"truseo_locale":null},"gt_translate_keys":[{"key":"link","format":"url"}],"_links":{"self":[{"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/posts\/30649","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/comments?post=30649"}],"version-history":[{"count":2,"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/posts\/30649\/revisions"}],"predecessor-version":[{"id":159238,"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/posts\/30649\/revisions\/159238"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/media\/22639"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/media?parent=30649"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/categories?post=30649"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/tags?post=30649"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}