Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Repair command deletes remote files for new backups #3416

Open
Livven opened this issue Oct 8, 2018 · 4 comments

Comments

Projects
None yet
2 participants
@Livven
Copy link

commented Oct 8, 2018

  • I have searched open and closed issues for duplicates.

Environment info

  • Duplicati version: 2.0.3.3_beta_2018-04-02
  • Operating system: Windows 10 1803
  • Backend: OneDrive

Description

Running the database repair command can cause data loss. This should never happen.

Steps to reproduce

  1. Add backup on PC 1 for an existing backup from another PC 2 so that files from PC 2 can be easily restored to PC 1.
  2. Restore some files on PC 1.
  3. Run the backup on PC 2.
  4. Run the database repair command on PC 1.
  • Actual result:
    All new backup files (from step 3) are deleted from the remote.
  • Expected result:
    The new backup (from step 3) should now be available and selectable from the file restore view on PC 1. At a minimum the files should not be deleted...

Screenshots

Debug log

MainOperation: Repair
RecreateDatabaseResults: null
ParsedResult: Error
EndTime: 09.10.2018 00:19:01 (1539037141)
BeginTime: 09.10.2018 00:16:52 (1539037012)
Duration: 00:02:09.3987071
Messages: []
Warnings: []
Errors: [
    Failed to accept new index file: duplicati-i0c1445caa4b845d882ce766251164713.dindex.zip.aes, message: Volume duplicati-b8ef173135e134164af8b16c6cea4b94b.dblock.zip.aes has local state Deleting => Volume duplicati-b8ef173135e134164af8b16c6cea4b94b.dblock.zip.aes has local state Deleting,
    Failed to accept new index file: duplicati-i0e57eee9039b437c941ffe354faf0a0f.dindex.zip.aes, message: Volume duplicati-b64286173307b4f45bae7e1c35cfbcbf7.dblock.zip.aes has local state Deleting => Volume duplicati-b64286173307b4f45bae7e1c35cfbcbf7.dblock.zip.aes has local state Deleting,
    Failed to accept new index file: duplicati-i1a724a86bf4040a8ba560c543ebd7fe1.dindex.zip.aes, message: Volume duplicati-b7c8ecc9280c54cf8a62750800c5719d8.dblock.zip.aes has local state Deleting => Volume duplicati-b7c8ecc9280c54cf8a62750800c5719d8.dblock.zip.aes has local state Deleting,
    Failed to accept new index file: duplicati-i1d39bcead2be4deb99eedfdc67a8d4ce.dindex.zip.aes, message: Volume duplicati-b500b479743694ae286f980193a0e21a2.dblock.zip.aes has local state Deleting => Volume duplicati-b500b479743694ae286f980193a0e21a2.dblock.zip.aes has local state Deleting,
    Failed to accept new index file: duplicati-i1e92e43e008040999087cc168c2d2d77.dindex.zip.aes, message: Volume duplicati-bf1f007d159584c25bdc263a8915e1e2c.dblock.zip.aes has local state Deleting => Volume duplicati-bf1f007d159584c25bdc263a8915e1e2c.dblock.zip.aes has local state Deleting,
...
]
BackendStatistics:
    RemoteCalls: 159
    BytesUploaded: 0
    BytesDownloaded: 5702589
    FilesUploaded: 0
    FilesDownloaded: 49
    FilesDeleted: 109
    FoldersCreated: 0
    RetryAttempts: 0
    UnknownFileSize: 0
    UnknownFileCount: 0
    KnownFileCount: 161
    KnownFileSize: 3214555629
    LastBackupDate: 08.10.2018 12:14:02 (1538993642)
    BackupListCount: 21
    TotalQuotaSpace: 1144608784384
    FreeQuotaSpace: 193318938059
    AssignedQuotaSpace: -1
    ReportedQuotaError: False
    ReportedQuotaWarning: False
    ParsedResult: Success
@Pectojin

This comment has been minimized.

Copy link
Member

commented Oct 11, 2018

Best way to deal with this would be to have a representation of a "backup reader" configuration. The issue only occurs because you technically configured 2 Duplicati instances to back up to the same destination.

I know that's not your intention, but for all Duplicati knows that's what it looks like.

@Livven

This comment has been minimized.

Copy link
Author

commented Oct 11, 2018

Ah okay, that kinda makes sense. I think there are two issues here - (1) the fact that there is no official "backup reader" configuration, as you said, but (2) even then the repair command should not cause data loss with this or any other kind of misconfiguration.

@Pectojin

This comment has been minimized.

Copy link
Member

commented Oct 11, 2018

I agree it shouldn't, but it's not entirely straight forward to solve from a technical perspective. PC 1 thinks it's removing invalid files from it's own backup destination.

I'm hoping someone has a good idea.

@Pectojin

This comment has been minimized.

Copy link
Member

commented Oct 11, 2018

Just brainstorming, but you might be able to mimic this behavior with --no-local-db

"When listing contents or when restoring files, the local database can be skipped. This is usually slower, but can be used to verify the actual contents of the remote store"

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.