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 EA5C015838C for ; Tue, 30 Jan 2024 19:19:27 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id DD406E2B42; Tue, 30 Jan 2024 19:19:22 +0000 (UTC) Received: from mail-lf1-f49.google.com (mail-lf1-f49.google.com [209.85.167.49]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id 7DED3E2B3C for ; Tue, 30 Jan 2024 19:19:22 +0000 (UTC) Received: by mail-lf1-f49.google.com with SMTP id 2adb3069b0e04-5102b00c2cdso3868272e87.3 for ; Tue, 30 Jan 2024 11:19:22 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1706642360; x=1707247160; h=content-transfer-encoding:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=/dRYmjvFnO/NYp58H0NrrCS4g486x0rTGZBHEsR8xYI=; b=dpD6HHvfZagi75quuuoKNfjDp/PUxkD9dVaPmPlmLgrXZwo7eojaFguHHrq57u0x+v dpcBOPmljZ1ziAeOBKkGM1drJVjjkgSxK2qnFsBIlPxmaEtDa0t59qV5JQF/CzgWJFUf Tc/mObRoWX+5LyeTOLqS17gSgEUwLKbbwQ5RdmUV2qB6PUHff8FH7+lt+eWvkcIMi3O6 VKi29wfOI2WcB6DdCYu/fJoDcLZqPc06PXbNXam5Yks+DGO3EmgyFeIk7UrudLwECa2C f6Z5OduU3IWcZx+Td2JiVRGEVXtpdAQaKsYLnTDDi9qm+8Mambtn56pYEW7WO19BLn0A T3rA== X-Gm-Message-State: AOJu0Yy16+uoarLLfsIhDpxnx7q6/D+G7yvtn5KYEi2/xQPbUEqRurxM b9/G/lmDeX/SLyWq+9Yy904EvxPyGsEGLw6MGfRQ0QWJtssOoDC5hgtDX764l5UYLxXlw8lN+bc EO2wDoIIM9256CCYxZKdEtsnyIzg782Iy X-Google-Smtp-Source: AGHT+IEVShQc7PpOXIEeJuTe0bPbNkQPn2ttnWIJLxBIe0WgUTqZxuwtV667QKoeHPypSE8ZbsTeCP9hKD4JauQfxCw= X-Received: by 2002:a05:6512:282c:b0:511:1fb0:1f71 with SMTP id cf44-20020a056512282c00b005111fb01f71mr1770327lfb.51.1706642359877; Tue, 30 Jan 2024 11:19:19 -0800 (PST) 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 References: In-Reply-To: From: Rich Freeman Date: Tue, 30 Jan 2024 14:19:08 -0500 Message-ID: Subject: Re: [gentoo-user] Suggestions for backup scheme? To: gentoo-user@lists.gentoo.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Archives-Salt: 1c22bffa-bd46-41f1-980c-8edf5c051cfb X-Archives-Hash: d37f6e58c4da4f08de694761688c171b On Tue, Jan 30, 2024 at 1:15=E2=80=AFPM 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. 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. 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. 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. There are some scripts out there that automate the process of managing all of this (you need to maintain snapshots/etc to allow the incremental backups). There are a bunch of other tools for backing up specific applications/filesystems/etc as well. (Every database has one, which you should definitely use, and there are tools like volsync for k8s and so on.) 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. 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. If you have windows hosts you want to backup then be sure to find a solution that supports volume shadow copy - there aren't many. Bacula is one of them which is the main reason I even use it at this point. If you don't have that feature then you won't back up the registry, and you can imagine how losing that is on a windows machine. If you're just backing up documents though then anything will work, as long as files aren't open, because windows is extra-fussy about that. --=20 Rich