Stories
Slash Boxes
Comments

SoylentNews is people

SoylentNews is powered by your submissions, so send in your scoop. Only 15 submissions in the queue.
posted by janrinok on Tuesday February 06, @03:51AM   Printer-friendly
from the confidentiality-integrity-and-availability dept.

Exotic Silicon has a detailed exploration of how and why to make long term backups.

The myth...

When thinking about data backup, many people have tended to fixate on the possibility of a crashed hard disk, and in modern times, a totally dead SSD. It's been the classic disaster scenario for decades, assuming that your office doesn't burn down overnight. You sit down in front of your desktop in the morning, and it won't boot. As you reach in to fiddle with SATA cables and clean connections, you realise that the disk isn't even spinning up.

Maybe you knew enough to try a couple of short, sharp, ninety degree twists in the plane of the platters, in case it was caused by stiction. But sooner or later, reality dawns, and it becomes clear that the disk will never spin again. It, along with your data, is gone forever. So a couple of full back-ups at regular intervals should suffice, right?

Except that isn't how it usually happens - most likely you'll be calling on your backups for some other reason.

The reality...

Aside from the fact that when modern SSDs fail they often remain readable, I.E. they become read-only, your data is much more likely to be at risk from silent corruption over time or overwritten due to operator error.

Silent corruption can happen for reasons ranging from bad SATA cables and buggy SSD firmware, to malware and more. Operator error might go genuinely un-noticed, or be covered up.

Both of these scenarios can be protected against with an adequate backup strategy, but the simple approach of a regular, full backup, (which also often goes untested), in many cases just won't suffice.

Aspects like the time interval between backups, how many copies to have and how long to keep them, speed of recovery, and the confidentiality and integrity of said backups are all addressed. Also covered are silent corruption, archiving unchanging data, examples of comprehensive backup plans, and how to correctly store, label, and handle the backup storage media.

Not all storage media have long life spans.


Original Submission

 
This discussion was created by janrinok (52) for logged-in users only, but now has been archived. No new comments can be posted.
Display Options Threshold/Breakthrough Mark All as Read Mark All as Unread
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
  • (Score: 3, Interesting) by boltronics on Wednesday February 07, @03:04AM

    by boltronics (580) on Wednesday February 07, @03:04AM (#1343448) Homepage Journal

    RAID can improve uptime in the event of a disk failure, but RAID is not a backup, and it can introduce problems.

    For example, imagine a simple RAID1 array, where the RAID controller or the drives are silently introducing corruption. You now have two drives with different contents. Which one is correct? Without at least three disks, it may not be possible to know. Since there were two disks, you doubled the chance of this problem occurring.

    If you delete a file on your filesystem running on RAID, it's gone for good. That's not the case with an actual backup.

    I personally use btrfs in linear/JBOD mode across two SSDs for my desktop. If an SSD fails and my computer crashes, it's not the end of the world. I get the benefits of checksums, being able to run a scrub, perform resizing, etc.

    I have my backups hosted on another machine, taken using a script I made many years ago (hosted here [github.com] if curious). It uses rsync over SSH and hard links to create a structure like so (where the number of backups kept for each interval type can be adjusted as needed):


    root@zombie:/var/local/backups/pi4b-0.internal.systemsaviour.com/root# ls -l
    total 64
    drwxr-xr-x 19 root root 4096 Jan 24 09:56 daily.0
    drwxr-xr-x 19 root root 4096 Jan 24 09:56 daily.1
    drwxr-xr-x 19 root root 4096 Jan 24 09:56 daily.2
    drwxr-xr-x 19 root root 4096 Jan 24 09:56 daily.3
    drwxr-xr-x 19 root root 4096 Jan 24 09:56 daily.4
    drwxr-xr-x 19 root root 4096 Jan 24 09:56 daily.5
    drwxr-xr-x 19 root root 4096 May 30 2023 monthly.0
    drwxr-xr-x 19 root root 4096 May 30 2023 monthly.1
    drwxr-xr-x 19 root root 4096 May 30 2023 monthly.2
    drwxr-xr-x 19 root root 4096 May 30 2023 monthly.3
    drwxr-xr-x 19 root root 4096 May 30 2023 monthly.4
    drwxr-xr-x 19 root root 4096 May 30 2023 monthly.5
    drwxr-xr-x 19 root root 4096 Jan 24 09:56 weekly.0
    drwxr-xr-x 19 root root 4096 May 30 2023 weekly.1
    drwxr-xr-x 19 root root 4096 May 30 2023 weekly.2
    drwxr-xr-x 19 root root 4096 May 30 2023 yearly.0
    root@zombie:/var/local/backups/pi4b-0.internal.systemsaviour.com/root# ls -l yearly.0/
    total 68
    lrwxrwxrwx 16 root root 7 Apr 5 2022 bin -> usr/bin
    drwxr-xr-x 4 root root 4096 Nov 15 11:28 boot
    drwxr-xr-x 3 root root 4096 Jan 1 1970 boot.bak
    drwxr-xr-x 2 root root 4096 Dec 19 20:06 dev
    drwxr-xr-x 93 root root 4096 Dec 31 20:20 etc
    drwxr-xr-x 3 root root 4096 Jun 15 2022 home
    lrwxrwxrwx 16 root root 7 Apr 5 2022 lib -> usr/lib
    drwx------ 2 root root 4096 Apr 5 2022 lost+found
    drwxr-xr-x 2 root root 4096 Apr 5 2022 media
    drwxr-xr-x 2 root root 4096 Apr 5 2022 mnt
    drwxr-xr-x 3 root root 4096 May 30 2023 opt
    dr-xr-xr-x 2 root root 4096 Jan 1 1970 proc
    drwx------ 4 root root 4096 Jan 1 00:14 root
    drwxr-xr-x 25 root root 4096 Jan 1 00:23 run
    lrwxrwxrwx 16 root root 8 Apr 5 2022 sbin -> usr/sbin
    drwxr-xr-x 2 root root 4096 Apr 5 2022 srv
    dr-xr-xr-x 2 root root 4096 Jan 1 1970 sys
    drwxrwxrwt 2 root root 4096 Jan 1 00:14 tmp
    drwxr-xr-x 11 root root 4096 Apr 5 2022 usr
    drwxr-xr-x 11 root root 4096 Apr 5 2022 var
    root@zombie:/var/local/backups/pi4b-0.internal.systemsaviour.com/root#

    This makes it very easy to recover a single file, or all files on an entire filesystem (where I take the stance that anything below the filesystem level can always be recreated easily enough). I actually had to use it to recover from a failed SD card in a Raspberry Pi the other day (which I use to host my website). It also provides for the possibility to check for filesystem corruption by identifying which files are not hard links between any two snapshots (and check for any unexpected differences).

    --
    It's GNU/Linux dammit!
    Starting Score:    1  point
    Moderation   +1  
       Interesting=1, Total=1
    Extra 'Interesting' Modifier   0  
    Karma-Bonus Modifier   +1  

    Total Score:   3