It basically combines your external drive and SSH server to a RAID-1 array
You could also use both the SSH server and external drive concurrently during backups and set fault redundancy to 1. That would let you restore your data as long as one of the backup targets is available.
That is not a problem since I prefer to trigger my backups manually and not automated. Does fault redundancy 2 then mean, the backup would only be started if both targets are available?
1 reply
Okay, yea so fault tolerance levels might be overkill for my scenario then
How does knoxite deal with connection loss during a backup or a restore?
indeed, just thought I'll point it out as it's probably knoxite's unique selling point. I don't think anyone else does that
During a backup that should be a fatal error, as it can't guarantee your data is safely stored.
During a restore you can let it try continue restoring data
There's also the
--pedantic flag, which makes it abort on the first error
So say for example a big file gets backed up, and halfway the connection drops. Then obviously on the remote repo, there is a corrupted backup or at least corrupted chunks.
All good questions, really! Only if it tries to store the same chunk of data again, but often that's the common scenario: the backup operation aborts with an error, you restart it, it would clean up after itself
if you just ignore the error, then yeah, it would obviously be left in a dangling state. A
restore or verify operation would also detect that tho.
it wouldn't know where the original data stems from, so yeah, it can only inform at that point
the snapshot wouldn't be created in that case, as that's finished as the last part of the transaction
so technically, depending on when exactly it aborts you couldn't even try to restore or verify
retrying the same backup operation would detect the existing chunks in storage however and would not overwrite the existing data. It pretty much picks up where it left off during the last backup operation.
of course
Knoxite has volumes and snapshots. Snapshots are clear, but are volumes kinda like partitions on a disk?
So the way I understand them right now, it makes sense to use them to separate different content in the same repo. For example have one volume music, another one personal data, and one for movies or something like that.
ANd then for each of them I manage snapshots
So the way I understand them right now, it makes sense to use them to separate different content in the same repo. For example have one volume music, another one personal data, and one for movies or something like that.
ANd then for each of them I manage snapshots
Is that correct?
Yep, that's how I use it. Also if you backup a farm of servers, you could have a volume per machine
(and still benefit from data deduplication across multiple machines)
How would I remove a snapshot with knoxite? The documentation only mentions removal of volumes
(Because I can see removing a snapshot not being trivial because of all the deduplication functionality)
There is
knoxite snapshot remove [id]. If that's missing from the docs, that's an oversight :)
This will indeed only delete the metadata. If you want to also remove chunks that are now not associated with any snapshot anymore (data deduplication), you would have to use
knoxite repo pack manually.
This will indeed only delete the metadata. If you want to also remove chunks that are now not associated with any snapshot anymore (data deduplication), you would have to use
knoxite repo packmanually.
Perfect!
A
.gitignore like feature would be super neat indeed, but doesn't exist yet.
You can however filter the files beforehand, and then pass the file-set to knoxite
I wonder if there's a cli tool that parses .ignore files and returns the resulting list of filtered fiels/dirs
if not, there totally should be one :D
Not sure if there are any for go tho
for Go, I actually wrote one myself: https://github.com/muesli/gitcha