Best way to create backup on cloud for EPUB books

[Quoth]

Originally Posted by Wiggo

What's not to understand about incremental backup?

Mmm, lots. You need to test it. I do use it for the OS (and thus all installed programs). Also for all the files on the server. I do prefer complete copies of any new files or changed files done with rsync, or sometimes manually, for the user files.

Restore of an accidentally deleted local file from an incremental backup can be slow.

[Sirtel]

My backups have been tested in real life every time I've gotten a new laptop or tablet. In total 6 times in 12 years.

It's never a good idea to use only one backup method. That's why I use both external drives and Dropbox, so I won't have to rely solely on either of them. A friend's or a relative's house is not an option for me, as I already said.

[Sirtel]

Originally Posted by Quoth

Mmm, lots. You need to test it. I do use it for the OS (and thus all installed programs). Also for all the files on the server. I do prefer complete copies of any new files or changed files done with rsync, or sometimes manually, for the user files.

Restore of an accidentally deleted local file from an incremental backup can be slow.

I've never accidentally deleted a file beyond recovery. Accidental deleting of anything is an extremely rare occurrence for me and in those very few instances it has actually happened I've been able to immediately get another copy from one of my many backups.

If you're constantly accidentally deleting something you shouldn't have, then perhaps it's a good idea to change something in your workflow.

[chaley]

Originally Posted by Sirtel

It's never a good idea to use only one backup method. That's why I use both external drives and Dropbox, so I won't have to rely solely on either of them. A friend's or a relative's house is not an option for me, as I already said.

Put me in the paranoid camp.

For more than 10 years I have used three: my NAS (Synology and Acronis), Dropbox (for some things), and a cloud incremental file backup service (LiveDrive). Each had its advantages and disadvantages. I have upgraded/recovered our computers multiple times over those years and have always been able to use the backup on my NAS to get my data. I have used LiveDrive when recovering some stuff when travelling or when I needed something older than I keep on the NAS. I use Dropbox when I want 2-way sync or access from our phones.

Recovering/upgrading a machine from the NAS is relatively easy. Recovering it from LiveDrive is more difficult because it doesn't have OS images, but doable (I have done it). Dropbox is for convenience.

[Quoth]

Originally Posted by Sirtel

I've never accidentally deleted a file beyond recovery. Accidental deleting of anything is an extremely rare occurrence for me and in those very few instances it has actually happened I've been able to immediately get another copy from one of my many backups.

If you're constantly accidentally deleting something you shouldn't have, then perhaps it's a good idea to change something in your workflow.

Yes. However my comment is based on experts and my own experience of IT Support. Obviously loads of careful people might have accidental deletion at the bottom of the list. However it is the most common data loss. Or an intended copy in GUI drag and drop is really a move and accidentally "dropped" in the wrong place and the user can't find it.
Then there was the secretary that for several years was using one file for all correspondence and printing highlighted range. Yet was expert at paper filing.

[nabsltd]

Originally Posted by Sirtel

Me, I will never allow an active library to reside on a networked drive, as you do.

Note that when using Windows networking (not just SMB/CIFS, but actual Windows on both client and server), the semantics of the connection are such that there is no difference between local and networked. Even the response to the write point becoming unavailable (e.g., remove a data cable from a local drive or pull the network cable) looks the same as far as the software is concerned.

As a matter of fact, if the software doing the writing (e.g., Calibre) doesn't do some serious low-level checking, the library could be on a network drive and the software has no clue, because of the ability to use symbolic links that point directories or files to another machine.

I wouldn't put my Calibre library on a network drive simply because there's no value in it...you can't run multiple instances of Calibre on the same database, so there's nothing to gain by making it available to multiple machines at the same time.

[Quoth]

Originally Posted by nabsltd

Note that when using Windows networking (not just SMB/CIFS, but actual Windows on both client and server), the semantics of the connection are such that there is no difference between local and networked.

Source for this astounding claim?

[ownedbycats]

Originally Posted by Turtle91

If you don’t want to pay a subscription for cloud storage you can use the technique mentioned by Sirtel to mirror it to a usb drive. Those drives a very inexpensive and will easily hold the entire library of thousands of books.

You can either just copy the folder that holds your books to the usb, or other external, drive - OR - you can use Calibre’s LibraryExport function. That function makes a Calibre restorable folder you typically use if transferring your library from one computer to another. It’s a larger folder than just copying the library folder, but it still easily fits in a usb drive.

Use a quality USB drive, too; cheap ones wear out faster.

Personally, I'd prefer a portable spinning rust hard drive. Be careful when it's running, I had a head crash by accidentally bumping one.

[ownedbycats]

Originally Posted by Quoth

This applies always since computer backups existed about 70+ years ago.

A disaster recovery plan (backups are part of it) is useless unless tested. You do need a spare computer, or at least a second one (not identical, but compatible, like ARM, 32 bit Intel, 64 bit AMD etc and enough space to restore and enough RAM to run). You can get even an old 64bit desktop with enough RAM (2G Linux, 4G Windows) for free if you ask around. It will do to test restore of your Calibre, or MS Word/LO Writer docs, or spreadsheets, or accounts or whatever.

Some files on a cloud service is more suited to sharing than any serious backup / disaster recovery plan.

Order of likely disasters:

1. User accidental deletion
2. Theft at internet cafe, conference or travelling.
3. SSD or HDD fail (no advance warning on SSD, can be on HDD). Seen a PSU fail destroy all PCBs (HDD was recovered by swapping its PCB, less likely now).
4. Ransomware or similar
5. Theft at home
6. Fire / flood etc at home
7. Law enforcement seize it. They'd get cloud too, but might miss a friend or safe deposit box. You could be innocent.

Also any cloud service can be closed, hacked or whatever. It's only someone else's computer and they may not be honest about security or backups (or tell you there is no backup). Hosting is often more secure than separate "cloud storage" offerings.

I'm not sure what order it'd fall under, but there's been at least one Windows update that deleted user files (albeit under very specific circumstances: when the user folders were manually relocated, but user was also keeping files in the original folder )

[Quoth]

Originally Posted by ownedbycats

I'm not sure what order it'd fall under, but there's been at least one Windows update that deleted user files (albeit under very specific circumstances: when the user folders were manually relocated, but user was also keeping files in the original folder )

I forgot that. Also using "Roaming" profiles, server and more than one workstation on NT 4.0 could delete all the users files!

Ever since about 2000 (Windows NT 4.0, XP, 2000, Win 7, Win 10) I kept all the files I created in a separate directory on the root of a drive with my permissions and ownership.

So the list is missing a broad "IT configuration issues". Covers MS updates, inept restores, remote management gone wrong etc.

[nabsltd]

Originally Posted by Quoth

Source for this astounding claim?

Read the docs...Microsoft has hundreds of pages on how their networking works, and there are all sorts of fun things you can learn.

Mostly, it's related to the code that was added to allow a user to access a share on the local machine without incurring any penalty from the network stack. This has been expanded so that NTFS and ReFS semantics are the same regardless of whether you are local or remote.

Unless a program specifically checks to see if there is a reparse point with a non-local target somewhere between the root of the drive and the target file, there is no way to tell if the target is local or not. Usually, the only clue is when deleting files from Explorer you get the "permanently delete" warning just like you always do if there is no recycle bin.

It's not that Windows doesn't actually know the filesystem is remote...it's just that the behavior is same as a local filesystem, because Windows knows the other end supports all the same functions.

[Quoth]

Originally Posted by nabsltd

Read the docs...Microsoft has hundreds of pages on how their networking works, and there are all sorts of fun things you can learn.

Yes, I passed exams in it and also real engineering. You are mistaken. It's not as simple as what you think.

I used to write Windows server / services and other applications using MS Networking, and Named Pipes. Also non-NT Windows never fully implemented Lan manager or other networking apis. Mapping a share to a drive letter absolutely doesn't make it the same as a local drive mount. That's fantasy.

[DNSB]

And when we were playing with the network grunger at work, anything shared over the network rapidly became unusable.

[nabsltd]

Originally Posted by Quoth

Mapping a share to a drive letter absolutely doesn't make it the same as a local drive mount.

"Mapping a share to a drive letter"...how quaint.

That said, if the target of a file operation is not local, but is on a Windows machine, you still get all the same semantics as if it were local. File locking, security, delete, rename, open, read, etc., all behave in exactly the same way. You have full access to the details of the NTFS file system (multiple streams, sparse files, compression, etc.). What you can't access are objects that deal with the volume itself (e.g., the MFT).

And, unless you trace from the top of the path all the way to the bottom, examining every step for reparse points, it's very hard to know if the file is not on a local drive.

[Quoth]

Originally Posted by nabsltd

"Mapping a share to a drive letter"...how quaint.

No drive letters on Linux. Nor were there on UNIX (which I used since 1986).

Sneering won't prove anything.