2

jrothlis :

Oct 26, 2013

Sounds AWESOME!

3

appel :

Oct 26, 2013

Excellent, Alex, thanks!

4

GoPiTM :

Oct 31, 2013

Sounds good can't wait to test it :D

5

tommyla :

Nov 23, 2013

i would like to have something like this too

6

Alex Pankratov :

Nov 25, 2013

(let me pin this thread to give it more eyes)

7

harrisc :

Nov 26, 2013

I know that I have told you before, but I re-enforce it.
I would like versioning when you are able to do it.
Chris

8

Eric :

Nov 27, 2013

Sounds good to me too !

9

PeteZ :

Dec 02, 2013

Great! This is the top major feature for my use.

Currently I rely on multiple versions of the same backup set (RT, hourly, daily, etc... ) to give me the ability to go back in file versions.

10

Alex Pankratov :

Dec 04, 2013

I hear you, guys. I just need to push this version into production first :)

11

scribbly :

Dec 06, 2013

File versioning is not what I use BvckUp for (SpiderOak does that for me), but having said that I'm now thinking of a couple of my BvckUp situations where it could come in handy. But it would need to be able to be finely controlled so that it doesn't duplicated any other versioning options in other software.

12

Curly :

Feb 17, 2014

Just a note on Git usage. I had a go at implementing Git backups based on the Bvackup files  (with a plan to use the post cmd line option to run Git)

However, Git choked on large files (probably the VMWare images). It's also not too good at storing large files in general. I did have a look at Git Annex (https://git-annex.branchable.com/) as this seems more suited, but then ran into the problem that trying to version 500m files on my slow Drobo-FS NAS took 4-days before I canned it :-) I might try again with a Drobo-5N.

13

Alex Pankratov :

Feb 17, 2014

@Curly - I'm not surprised git choked. It was certainly not designed for multi-gig files in mind. At least not as a priority. I also strongly suspect that it caches whatever it can in memory and/or uses memory-mapped file access, so that too would create severe usability problems with large files.

There's https://github.com/bup/bup and there's https://github.com/schacon/git-media, both seem stagnated (though former hit HN's front page just few days ago, so perhaps it will help reviving it). I haven't tried either, I just know they exist.

On a more general note, the more I think about all this, the more I'm inclined to widen the scope of it. Versioning is great, but if I am to venture into the data persistence domain, it would make sense to also look at bitrot protection, redundancy and other interesting things ... :)

14

Curly :

Feb 18, 2014

Thanks for the links Alex, bup looks interesting. I'll have a play around with it.

15

InsertRealName :

Mar 12, 2014

New user here (Beta 63), and what chiefly impresses me about Alex's work is the dedication to the "keep it simple (but not more simple than it needs to be)" principles. This backup software does exactly one thing extremely and reliably, namely: keep an easily accessible, reliable copy of important files on a separate disk, and do it in the most efficient way possible once the initial copy has been made.

In that light, while file versioning is certainly something I'd like to see, I just cannot understand the desire to adapt something as complex as the 3rd party Git version management libraries: Git's versioning is made for a whole other order of versioning complexity and strategies. It's almost as if Alex wanted to be permanently subject to headaches and possible episodes of insanity.

What I would expect from Alex (if I understand his mode of development rightly) is for him to exploit the delta versioning code he has already created and knows inside-out to the more complex task of keeping multiple versions of a file in a space/time efficient format on the backup volume, while making it easy for the user to extract earlier versions when needed. In other words, no more than that actually needed for the task.

My very naïve suggestions: keep the current backup version just like it is now on the backup volume, but also store in a separate place reverse deltas for each file and the metadata necessary for enumerating, reconstructing and verifying file versions. Make a command line tool (also stored on the backup volume) that accepts a specification of the file(s) to be restored and the version(s) the user wants, e.g. bvuckup2 --restore --date ="2 months ago" \Users\XXX\Documents\GreatNovel.chap*.txt This command line tool could also accept a command specification (a bit like the Subversion SVN version control tools) that allows it to be driven from a separate GUI.

16

Alex Pankratov :

Mar 13, 2014

I just cannot understand the desire to adapt something as complex as the 3rd party Git version management libraries

Who said anything about adapting other people's code? :)

Git's versioning is made for a whole other order of versioning complexity and strategies.

What git has is a deduplication mechanism in a form of packfiles and support for maintaining, addressing and extracting multiple revisions of a single named entity. This is *exactly* what an archiving facility needs.

My very naïve suggestions: keep the current backup version just like it is now on the backup volume, but also store in a separate place reverse deltas for each file and the metadata necessary for enumerating, reconstructing and verifying file versions.

Precisely. Just go on a bit further - you have the reverse deltas, how do you store them? Quite a few of them will be redundant to each other (think of massive zero blocks or similar). So you would probably construct a storage that indexes blocks by their hashes and then have a reverse delta to be just a list of block indecies. Guess what, we just recreated git's packfiles :)

Make a command line tool (also stored on the backup volume) that accepts a specification of the file(s) to be restored and the version(s) the user wants, e.g. ...

Well, again - precisely :)

My point all along was to store the archive in an open format, not to adopt git toolchain for managing it, because that'd be quite an adventure for a lot of people.

17

InsertRealName :

Mar 13, 2014

O.K., I totally misunderstood your intent: you want to use the tested Git archive formats and archiving mechanisms, not the toolchain: that seems very reasonable, and might give people assurance they are not locked into a proprietary format.

Git just seems such a massive stack of software, although I suppose the lower levels that actually manage the archive formats are by now well developed and relatively tractable. I hope you'll be able to bury all that complexity with the external simplicity you've managed so far, which is one of your advantages and why I reacted so strongly.

18

TerryWood :

Apr 26, 2014

Hi Alex

I would like to add my support for versioning. It is the one missing function that is stopping me using Bvckup2 permanently in an otherwise superb program.

Terry

19

Alex Pankratov :

Apr 27, 2014

Terry, thanks, noted.

20

ckline :

Jun 19, 2014

Throwing my hat in the ring too. I use Bvckup2 in order  to copy source code files from my dev VM to my host machine, to prevent data corruption if the VM crashes. Unfortunately, without versioning, if I fire the VM back up and forget to grab the backup files first, Bvckup2 might copy the corrupted version over top of the good backup.

Adding even a simple double-buffering scheme for backup versions in the short term would make a big difference. Otherwise, Bvckup2 is excellent; money well spent.

21

PaulK :

Aug 28, 2014

I'd like to see this as well. I have an analyst who wants to run a backup of 6 key databases every 10 minutes each hour. He wants to keep the last 6 (therefore if he has to restore to a previous version it's never more than 10 minutes old). To accomplish this he's created 6 jobs pointing to 6 different destination folders.

If we had some version control we could have one job going to one destination keeping the last 6 versions of the files.

However, I also understand (and very much appreciate) the goal to keep this tool simple and effective. Tough call.

22

Theus :

Aug 28, 2014

Hello!

I am also new (beta 68) and am testing and loving Bvckup 2 <3
Just miss even the versioning of files, but otherwise is perfect. Are there any plans to release it or just have to wait? :(

23

Alex Pankratov :

Aug 29, 2014

I can't release it, because it's not done yet :) As I've mentioned earlier, this is a fairly complex feature that will take some time and effort to implement *efficiently*. As such it's likely to be a part of Bvckup 3, meaning that it's good several month to a year away.

24

wtip :

Oct 12, 2014

I just stumbled across this backup program and I am really liking everything I am seeing on the website. I like that everything has a very clean look. I personally don't need something that is simple as in dummy proof but I am sick of all these overly complicated backup solutions with 10 different software packages.
I'd really also like to see versioning.
Does the "Archiving of deleted items" only apply to files that are actually deleted. Files that are changed don't get archived? I'm guessing this is what I would need the versioning feature for.

I might just have to buy a license to show my support. I like where things seem to be heading after reading some comments by the developer on this forum.

25

genl :

Oct 13, 2014

Does the "Archiving of deleted items" only apply to files that are actually deleted. Files that are changed don't get archived?

Correct. That's how it works now.

26

wtip :

Oct 13, 2014

I'm curious if anyone is using bvckup2 in combination with some other software to do versioning and possibly also have some kind of bit-rot protection? I know spideroak was mentioned but I'm specifically interested in a solution that uses local storage and does not require using a cloud service.
I had this crazy idea of running something like freenas or rockstor in a VM so that I can use ZFS or Btrfs with snapshots and bit-rot protection. Then have bvchup2 backup to a SMB share on the VM. The VM would be running on the system I am trying to backup data from. I don't want to have to run a separate server just so that I can do backups once in a while for my one PC.

27

Alex Pankratov :

Oct 13, 2014

That's actually pretty sensible setup if you ask me. I've been meaning to throw zfs in my backup mix for a while now, but for now I simply back up to several identical USB drives.

28

traxit :

Dec 02, 2014

+1 push for that feature so i have a good all in one backup.

29

solflekken :

Jan 03, 2015

I would like this option!

30

Ragewind :

Jan 08, 2015

Even if a release of this feature is not due anytime soon I'm also looking forward to it. This will be a major step forward.

31

ckline :

Jan 21, 2015

I would also like this option very much.

This is particularly important to handle the case of a crash causing a file on the source media to become corrupted -- in this case, if you forget to disable the backup process prior to the (unfortunately non-configurable) "No backups after a reboot or wake-up for 5 minutes" threshold, your good backup is over-written by the corrupted file.

I've already been bitten by this multiple times.

32

ckline :

Jan 21, 2015

To be clear, I'm not looking for any fancy SCC-like versioning based on diffs. I'd be happy with just wasting disk space and storing multiple copies of files in the destination (e.g. numbered versions like "file.txt.4"would be fine with me)

33

ckline :

Jan 21, 2015

Hmm, I see that Alex has added some unsupported support for this, as a stopgap until v3 comes out: https://bvckup2.com/support/forum/topic/502/2958

34

johnseers :

Mar 20, 2015

I implemented your stopgap support for versioning and it appears to work well. I am not sure what extra function will be in the real version. It is a really good feature and I look forward to your implementation in v3. I will have to look and see if v3 has a target date for release.  I am not sure why this has not been higher on your priority list. I was just beginning to think I would need to look around for another package with versioning when I saw this. A JIT feature no less!

Scarily the next day after I implemented it I had to use it and go back to restore a file. A life saver.  :)

35

Ghost :

May 06, 2015

Really looking forward to versioning. It's the only major thing missing imo. Is there any rough ETA on version 3, with the file versioning?

36

Alex Pankratov :

May 07, 2015

@Ghost - it ranges from several months to a year, but mostly it depends on how well this goes - http://pipemetrics.com/hiring.

37

harrisc :

Oct 07, 2015

Any chance versioning is coming soon?

38

Alex Pankratov :

Oct 08, 2015

That chance is pretty slim.

39

sunk818 :

May 01, 2017

I like Windows Previous Versions tab once I go into the Properties of a file. I've tried to use Dropbox in conjunction with Bvckup 2 with mixed results. Previous versions works in Dropbox, but their service is so slow to reveal the previous versions. I like the Git idea and if we have a way to compare versions using freeware like WinMerge (I personally use Beyond Compare Pro), that'd be great.

40

Lorenz :

Jun 12, 2017

Since the last post from Alex is 2 years old.. any update on the matter?
Thanks

41

Alex Pankratov :

Jun 12, 2017

Still in the queue, preceded by a handful of larger v2 features, including backup verification, UI support for various advanced features and SMART drive status monitoring.

42

LonDarum :

May 19, 2019

Is this feature already launched (or will be soon)? I'm switching from CrashPlan and this would be a killer feature for us.

Specifically, delta patches of versioned files, not just copying the full file around.

43

Alex Pankratov :

May 20, 2019

No, this feature hasn't launched and it's been further delayed until further notice. Basically, there are other features that are more useful to larger audiences, e.g. support for cloud storage, and these will come first.

delta patches of versioned files, not just copying the full file around.

*This* has been supported from the first beta release in a form of delta copying [1]. But the _archival_ of these deltas is what this thread is about and it's not implemented.