From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by finch.gentoo.org (Postfix) with ESMTPS id 9278815838C for ; Tue, 30 Jan 2024 19:43:16 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id F2BC02BC082; Tue, 30 Jan 2024 19:43:11 +0000 (UTC) Received: from ciao.gmane.io (ciao.gmane.io [116.202.254.214]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (prime256v1) server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id 5E788E299F for ; Tue, 30 Jan 2024 19:43:11 +0000 (UTC) Received: from list by ciao.gmane.io with local (Exim 4.92) (envelope-from ) id 1rUu0j-00061n-QK for gentoo-user@lists.gentoo.org; Tue, 30 Jan 2024 20:43:09 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: gentoo-user@lists.gentoo.org From: Grant Edwards Subject: [gentoo-user] Re: Suggestions for backup scheme? Date: Tue, 30 Jan 2024 19:43:02 -0000 (UTC) Message-ID: References: Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-user@lists.gentoo.org Reply-to: gentoo-user@lists.gentoo.org X-Auto-Response-Suppress: DR, RN, NRN, OOF, AutoReply Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit User-Agent: slrn/1.0.3 (Linux) X-Archives-Salt: d9484406-52fa-4583-b672-12af25601891 X-Archives-Hash: 6abd9a827ffdd782aa0268aa3a6b6220 On 2024-01-30, Rich Freeman wrote: > On Tue, Jan 30, 2024 at 1:15 PM Grant Edwards wrote: >> >> Are there other backup solutions that people would like to suggest I >> look at to replace rsnapshot? I was happy enough with rsnapshot (when >> it was running), but perhaps there's something else I should consider? > > I'd echo the other advice. It really depends on your goals. FWIW, I'm backing up only home directories and config stuff (e.g. /etc). I don't backup the OS itself or anything installed in /opt by installers or ebuilds. > I think the key selling point for rsnapshot is that it can generate a > set of clones of the filesystem contents that are directly readable. Yes, that's the main advantage of rsnapshot. You can browse through backups without any special tools. > That isn't as efficient as it can be, but it is very simple to work > with, and it is done about as well as can be done with this sort of > approach. Restoration basically requires no special tooling this > way, so that is great if you want to restore from a generic rescue > disk and not have to try to remember what commands to use. Yep, rsnapshot can take several hours to run every night. But, being able to look through backups with nothing more than "cd" "ls" and "cat" sure is nice. > send-based tools for filesystems like brtrfs/zfs are SUPER-efficient > in execution time/resources as they are filesystem-aware and don't > need to stat everything on a filesystem to identify exactly what > changed in an incremental backup. However, you're usually limited to > restoring to another filesystem of the same type and have to use those > tools. For now, I need something for ext4, but backup-ability is definitely a a reason to consider switching filesystem types. > Restic seems to be the most popular tool to backup to a small set of > files on disk/cloud. I use duplicity for historical reasons, and > restic does the same and probably supports more back-ends. These > tools are very useful for cloud backups as they're very efficient > about separating data/indexes and keeping local copies of the latter > so you aren't paying to read back your archive data every time you do > a new incremental backup, and they're very IO-efficient. I generally backup to a USB 3 external hard drive, so IO efficiency isn't as much a concern as when backing up to cloud. There are things I periodially back up to cloud, but that's generally a manual process involving little more than "scp". > Bacula is probably the best solution for tape backups of large numbers > of systems, but it is really crufty and unwieldy. I would NOT use > this to backup one host, and especially not to back up the host > running bacula. Bootstrapping it is a pain. It is very much designed > around a tape paradigm. Thanks, I'll cross that one off the list. :) > If you have windows hosts you want to backup Thankfully, I don't.