I’m looking for some FOSS to back-up my Ubuntu system and wonder what other people use.
I’m not asking about backing up my photos / my work, I can sort that.
Rather, it’s how to back up the system / OS so that e.g. if the disk fails, I can quickly and easily restore to a new disk and have Ubuntu running just as it was when backed up, minus my work.
Please note I’ve organised my disk (256Gb SSD in fact) as follows. A modest-sized partition for Ubuntu. A separate partition (the rest of the disk) for my work. I want the backup s/ware to work on the Ubuntu system, not the “work” (the latter would make the backups large and cumbersome, I’ll back up my photos separately). I think “system” includes a further small partition which the Ubuntu install makes anyway, and the boot sectors / Grub loader bits need to be part of the backed-up image also. And of course it would be nice if the image created included only the parts of the partition in use, and was compressed!
I don’t backup my system, rather I use dpkg --get-selections > pkgs.txt to dump a list of installed packages to my home dir. You can tell apt to install those packages. My dot files are in git and deployed with gnu stow.
In the second answer here, it is explained what is the drawback of --get-selections and how you can get a list of user-selected packages rather than all installed dependencies which may be not valid on a new setup, maybe if a new release of the host system is installed.
I can only comment what is working for me; I’m a Debian stable user and get-selections is working for what I need it to.
The forth comment on the first answer is why I don’t contribute much to Stack Exchange anymore, the “God this doesn’t work and you didn’t consider every single last use case” sort of comment that comes 6 years after the answer was posted.
Sorry @paperdigits, I didn’t mean to be offensive, I just wanted to contribute a solution that I found working reasonable. For me it’s simple: One solution gives a long list of packages installed, the other gives a short list of the packages that I selected for installation, but missing the ones that come with the distro preinstalled. Both can be the wrong decision, so maybe one should keep both lists. Especially when you decide to switch to a new version of the distro after replacing your broken harddisk (happens more often than one might think, for me, full harddisk comes close to broken ), it’s better to drop dependencies since they can cause a lot of trouble.
Seems I am the bad guy today, but the very first words on the what git-annex is not page state that it is not a backup system. Unfortunately this site does not explain why. Besides this, I use git-annex for some applications, but neither for system backup nor for photo management, but I intend to do the latter soon (but unfortunately time is a scarce resource these days).
Most certainly no offense taken @chris nor was your statement offensive to me.
“What comes preinstalled” might be easier to define on Ubuntu, but on Debian I always start from the netinstall Iso, get the most minimal base system (no Xorg, nothing selected in tasksel when installing), then I build my system up exactly the way I want it. So getting every package is OK for me, since my “base” install is really basic I probably wouldn’t use the get-selections file on a new operating system version, I’d probably go through the list by hand if that were the case. However, on Debian one can pretty safely dist-upgrade from one release to the next, so I wouldn’t wipe my machine and reinstall in order to upgrade to a new version anyway, so using get-selections for that usecase just doesn’t happen on Debian.
Thanks for the suggestions folks. I’ll look into clonezilla and systemback. Git-annex says it’s for git users who love the command line, so that rules me out twice over just for starters!
Git-annex is not a backup solution because it syncs files and does not sync binary file history. So if you change/overwrite a binary file in the annex, then do git-annex sync --content the new binary will propagate to your remotes. The old binary might still be there if one hasn’t run git annex unused and removed it, but git annex doesn’t try very hard to retain the copy of the old binary. That’s bad if your intention is for it to be a backup all by itself.
I wouldn’t use it for system backup either… my use case is to have a server with git-annex and a bunch of other computers with git-annex clients and sync all our files in one place. This happens to work as backup in case one of the disks fail but also it works as a kind of dropbox to sync files with your team. The great advantage here is of course it can handle big chuncks of raw video flawlessly.
Please don’t confuse file redundancy with backup. Git annex is great at giving you file redundancy, which is what you’ve described, but falls short in backup use case.
With that said I don’t do full backups system backups, just what I consider valuable data. I have a script to relatively quickly setup a new box, and enough boxes around so I can continue working.
I’ve used many backup tools over the years, including clonezilla, dejadup, custom scripts, basic cp commands, etc. I maintain about 10 Ubuntu systems between my personal computers and my lab on campus. I’ve never found a perfect solution, but recently I’ve really been enjoying aptik. It uses duplicity (and thus, rsync) as the engine and makes it easy to backup both files, settings, and program list. The developer is active and attentive (I’ve filed a few feature requests, and he got on it quickly!). So far, it’s been a pretty great piece of backup software…
), it’s better to drop dependencies since they can cause a lot of trouble.
. But I agree with you on that it’s great!