I'm Forwarding your conversation to rdiff-backup mailing list.
> From Bob Nichol's answer (yesterday) I understand that restoring a given
version of a file is by a reverse mechanism, that is, rdiff-backup starts
with the latest (most recent) version of a file and then goes backwards
until it finds the desired version.
It might not be totally true. I know rdiff-backup also generates a snapshot
of the files. I don't know exactly the mechanic about those. Possible Eric
Zolf may have more detail about when those snapshot get used in the restore
process.
> I had a chat with my customer an hour ago: They want the most recent
version and its immediate predecessor
It's perfectly doable with rdiff-backup. and you don't really have to do
anything special except running "remove-older-than" command line to clean
up old files
> Yesterday I tried a dry-run with rdiff-backup-delete for deleting
(dry-run) a small single file.
rdiff-backup is not really god at deleting stuff from a repository.
"rdiff-backup-delete" is a side script that need to go through all the
metadata and remove any reference to the file you are trying to remove.
Depending on your repository and hardware, it might take some time. 30 min
seams a bit long... But it's possible since we don't really know your
current setup.
> Analyzing the files on rdiff-backup media I found some old MS Office
files the names of which start "$" (files which were open during
rdiff-backup).
When you run rdiff-backup-delete with a dollar sign ($) you may need to
escape it to make your shell happy. Remember rdiff-backup-delete "$PATH"
might get replaced with your PATH environment variable. Your better to
place the filename in single quote. Your shell will not replace variable
name within single quote. So it's better to run rdiff-backup-delete '$PATH'
Also, to ease the management of your backup, you might take a look into
Rdiffweb.org if you want to browse and restore data from rdiff-backup repo.
Or Minarca.org if you also want an agent to schedule the backup of your
customer.
On Wed, Dec 21, 2022 at 11:51 AM Dieter Heußner <dieter.heuss...@mailbox.org>
wrote:
> Hello Patrik,
>
> > I'm following up with you regarding your question and to check if I can
> be
>
> > of any help.
>
> thanks a lot for your e-mail.
>
> From Bob Nichol's answer (yesterday) I understand that restoring a given
> version of a file is by a reverse mechanism, that is, rdiff-backup starts
> with the latest (most recent) version of a file and then goes backwards
> until it finds the desired version.
>
> I had a chat with my customer an hour ago: They want the most recent
> version and its immediate predecessor ("the two most recent version of any
> file") to be always available at any time.
>
> As far as I understand this can be achieved by standard implememtation of
> rdiff-backup. Or do I need some special configuration?
>
> If yes, which one?
>
>
> Yesterday I tried a dry-run with rdiff-backup-delete for deleting
> (dry-run) a small single file. It took a very long time (30 minutes) to
> walk through the whole repository. Is this normal?
>
> The basename of this file was "abc.~koi". So ran:
>
> rdiff-backup-delete --dry-run abc.~koi nameOfRepository
>
> As there are a lot of files ending on ".~koi", can I also use a wildcard
> argument, that is:
>
> rdiff-backup-delete [ --dry-run ] *.~koi nameOfRepository
>
>
> Analyzing the files on rdiff-backup media I found some old MS Office files
> the names of which start "$" (files which were open during rdiff-backup).
>
> Does rdiff-backup-delete accept a "$" as part of filename or must the "$"
> be escaped / masked by a preceeding "\" (e.g. "\$). I do not have the
> opportunity to test it right now, maybe in very late evening.
>
> Is it possible that my questions and your answers be available for other
> users of rdiff-backup and associated tools, please?
>
> > Otherwise I wish you a nice holiday season
>
> I also wish you nice holiday season!
>
> Best regards
>
> Dieter
>
>
>
> --------------------------------------------------------------
>
> PGP/GPG Key fingerprint:
>
> BF12 CD6F EDC4 9FBA C933 316B 2C81 0BEF 4324 8513
>
> --------------------------------------------------------------
>
>
--
*ATTENTION: Je serai en vacance du 24 Déc au 8 Jan.*
*ATTENTION: I will be on vacation from Dec 24 to Jan 8.*
IKUS Software
https://www.ikus-soft.com/
514-971-6442
St-Colomban, QC J5K 1T9
