1) Which general approach would be recommended to back up a drive containing documents and system images to Google Drive? Deletions are required in my use case, in order to avoid having a mess on Google Drive and also to avoid running out of space there. So, is there a practical difference between "Standard Copying" and "Exact Mirror" modes, if deletions would be enabled either way?
2) I have system images that can sometimes be ~100 GB in size. Can the .SZ format handle this, or would it be insane to try? Will I need to omit these image backup files and use a separate profile for them that uploads them as-is (i.e. no use of .ZIP nor .SZ)?
3) Can I use a password containing high-ANSI characters (e.g. ÷u¤›ZÆì%bÆŸ) with the .SZ file format?
4) Should I use "Filename Encoding", or does Google Drive preserve timestamps correctly?
General (and probably crazy) questions on backing up to Google Drive
Re: General (and probably crazy) questions on backing up to Google Drive
Hello,
if you need to mirror deletions, you need to choose "Exact Mirror" mode. Standard Copying does not do any deletions.
Under Files->Deletions in the profile, you can choose whether to use the Google Drive recycle bin for your deleted files.
The Sz format can theoretically handle these sizes, but it's not ideal for upload to Google Drive. You could try it with Compression "none". The other compression levels have to process the file twice: first to determine the final compressed size, and then another time to actually upload the file. The reason is that the Google Drive API requires knowing the final file size before starting the upload. The first compression pass is shown as "Precompressing" in the Syncovery progress. In fact I think it could be faster, I am working on it.
So it might be more efficient to work with zip or 7-zip and use local temporary files. If you just nee the encryption though, it should be fine.
A password like the example works find with Sz.
You do not need Filename Encoding. All modern clouds preserve modification timestamps just fine (except S3, which is actually pretty old, and some other insignificant clouds).
if you need to mirror deletions, you need to choose "Exact Mirror" mode. Standard Copying does not do any deletions.
Under Files->Deletions in the profile, you can choose whether to use the Google Drive recycle bin for your deleted files.
The Sz format can theoretically handle these sizes, but it's not ideal for upload to Google Drive. You could try it with Compression "none". The other compression levels have to process the file twice: first to determine the final compressed size, and then another time to actually upload the file. The reason is that the Google Drive API requires knowing the final file size before starting the upload. The first compression pass is shown as "Precompressing" in the Syncovery progress. In fact I think it could be faster, I am working on it.
So it might be more efficient to work with zip or 7-zip and use local temporary files. If you just nee the encryption though, it should be fine.
A password like the example works find with Sz.
You do not need Filename Encoding. All modern clouds preserve modification timestamps just fine (except S3, which is actually pretty old, and some other insignificant clouds).
Re: General (and probably crazy) questions on backing up to Google Drive
Thank you for the quick response and the answers.
And just to note, the reason I thought "Standard Copying" could do deletions was due to this statement in the help file (i.e. the "except" portion):
And just to note, the reason I thought "Standard Copying" could do deletions was due to this statement in the help file (i.e. the "except" portion):
Standard Copying
Standard copying will compare the files and folders present on each side, using the filenames, the "Last Modified" timestamps as well as the file sizes for comparison. Newer files and files that only exist on one side will be copied over to the other side. No files are deleted (except if you choose Real Time Synchronization and specify so on the Real Time settings dialog).
Re: General (and probably crazy) questions on backing up to Google Drive
Hi,
oh, OK, thanks. That statement is mostly misleading. It refers to the old real-time mode "Process Individual Events", which is generally not recommended. And it would only delete files if it actually sees and processes the event. If a deletion event is missed, possible because the scheduler is off or for whatever reason, such a missed deletion would never be done.
Whereas Exact Mirror will do deletions when it sees that a file no longer exists on the source, but still exists on the destination.
oh, OK, thanks. That statement is mostly misleading. It refers to the old real-time mode "Process Individual Events", which is generally not recommended. And it would only delete files if it actually sees and processes the event. If a deletion event is missed, possible because the scheduler is off or for whatever reason, such a missed deletion would never be done.
Whereas Exact Mirror will do deletions when it sees that a file no longer exists on the source, but still exists on the destination.
Re: General (and probably crazy) questions on backing up to Google Drive
I found that "Precompression" speed with compression level UltraFast is pretty fast, it just doesn't look that way.
Out of the 100% progress for one file, the first 5% are the precompression stage. So when 5% is reached, the actual upload starts.
Out of the 100% progress for one file, the first 5% are the precompression stage. So when 5% is reached, the actual upload starts.
Re: General (and probably crazy) questions on backing up to Google Drive
I would think that even if .SZ compression is "None" it will be pretty CPU- and maybe memory-intensive to process such large files. I think I will simply begin encrypting the backup images as they are created. Thanks.