I don't HDD backup; backing up files is easier
...and quicker.
About Backup Solutions:
“There are two types of people:
those who have suffered a catastrophic loss of data,
and those who will.”
When desaster strikes - and sooner or later it will - its's either no big deal at all. You have sufficient backups to fall back on. There may only the need to download, reinstall, and then copy things bayk. Annoying, yes, but no serious problem, no real damage done, since no data, no time you spent on things you produced and configured, is lost.
Or, if not, it's simply your backup plan ain't sufficient.
Backups by full storage drives and partition clones I did under Windows. I found no better way to backup a Windows system, since with Windows the system, its configs, partition schemes, and what unkown junk else are amalgamated to one ugly, inseparable cast part. Anything but nice.
There is software for that like
gparted-live, or clonezilla. But
dd does it also, if you just want to backup/restore full drives, and not align/resize partitions.
Pro: They are trivial to do. Nothing to setup, configure, think about... Just simple and easy save everything.
Cons: They save
everything. Drives are never full. With full drive BUs (clones) you also backup empty sectors, which is pretty pointless.
Also full drive BUs take way more time as it is practical for regular, not even daily BUs. So they cannot be done frequently enough to be really useful for normal production usage, but as part of larger system's modifications, only. If used as only BUs there is the trap your last BU is very old - too old, and with a restoration you enter the "way back time machine." Months of lost work and data could be the result.
And that's what's most importanat to be backed up: Your work. All and any data you spent time on.
The system itself is "throw away", 'cause it's easy to download and reinstall again. Even quickly done, when your backup-plan covers your system's config files, and a list of your packages installed.
pkg prime-list > mypackages.txt produces a textfile containing all names of all packages you installed on your system without version number, so a reinstallation of all packages can be automated easily.
Also the hardware is quickly replaceable. But no manufacturer's guarantee covers your paper you're working on for months, that has its deadline tomorrow.
Under a real OS (
) in almost all cases it's to backup the files.
That was the easy part.
Now it will become not really complicated, but it needs a bit effort to answer questions for to analyze the own situation, for to develop an own, reasonable backup plan.
First classify what to backup, e.g. by WISP:
- What? /home (of course!), config files(!): /etc, /usr/local/etc (X11 config), plus data, repositories,... /saved-games, /ex-partner-pix,... temp-files or trash.bin contents(?)
- Importance and value: Lifes depend on it, important, less important, unimportant, garbage ... How hard is it to get it again. How much effort takes it to reproduce?
- Size (some kB...several TB)
- Period frequency: How often to bu which data? monthly, weekly, daily,...every second? [snapshots]) Which data changes how often? You don't need to backup HD movie files (many GB up to TBs) every day, while you better backup your current production directories (several hundred kB up to a few MB) at least daily.
The amount of data to be backupped, the frequency how often the backups shall be done, the available storage capacity of where the backups live, and the bandwidth - how many byte per second can be transferred/written to the backup medium - needs to be evalutated as also where to backup to, which depends on severaö factors:
- What's reasonable? (Do large files which don't change need to stress a regulary BU routine?)
- What needs to be safe from what; own idiocy [#1 reason to restore from backups], hardware failure [can happen anytime, even on brand new hardware, #2], burning house, nature catastrophy, burglary, malware, cracker attack...
- How long need the backups endure (importance and frequency of change)
- Where to (additional single drive or mirror, NAS, flashdrive (not as BU medium; if even only unimportantjunk), cloudserver (
), tape, CD/DVD/BD,...) What's available? What's affordable? What suffices best for what?
- Available storage capacity
- Available bandwidth (1 kb/s...10 GB/s...?)
- How (cp, rsync, dump,... tar, compress, encryption,... incremental, non-incremental, self written shell scripts, backula,...verification)
- Redundancy (1x, 2x, 3x...extra copies)
It's obvious:
There cannot be given a general plan, except "Do backups!" -
"Do it! Do it! Do it! NOW!"
Everybody has to develop the own suiting plan based on the analysis of the very own situation.
Setting up a backup plan is not only part of setting up a system like think of which window manager to use, or to install packages, but the most important part.
Check, adapt, improve -
upgrade your backup plan
regulary is part of system's maintenence, any system's administration, no matter how stable or "safe" the system is.
It's even more important than to check for updates, and upgrades for softwarepackages, and less work when you have a good plan.
Anyway, I want to give a general tip, that seems "Duh! Obvious!" but may be underestimated when desaster striked:
Test the restoration! Really, actually do it!
All backup software, and backup strategies are worthless if you don't know how to get your data back, which ain't so certain to rely on if you never did it.
When the real event occurs - and it will - you will be anything but cool. So it's better you are at least cool and confident in knowing how to handle your restoration, to not mess things up even more.
See also:
The FreeBSD HB 20.8 Backup Basics
Backup - Wikipedia
"Backups aren't simple" by Aleksandar Filipovski
